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ABSTRACT 


Two algorithms for the mutual exclusion problem are described and 
proven to operate correctly. The algorithms are unique in that they use 
very simple Synchronization primitives yet are fair and retain their 
fairness even if the number of parallel processes in the computer system 
increases unboundedly over time. One of the algorithms uses simple cells 
of read/write storage as the primitive; the algorithm is similar to the 
classic algorithms for this problem proposed by Dijkstra and Knuth, but is 
generalized to handle an arbitrary number of processes. The second 
algorithm uses extended cells of storage that model read/modify/write 
(e.g. test-and-set) instructions. While it is well known how to use read/ 
modify/write instructions to achieve unfair mutual exclusion, their use in 
a fair algorithm is novel. 


The results prove that cells of read/write storage are sufficiently 
powerful primitives to achieve coordination of parallel processes. There 
is no theoretical necessity for a model of computation to include more 


sophisticated synchronization primitives such as semaphores and serializers. 


But while cells are sufficient, the algorithms are very inefficient; more 
sophisticated primitives are desirable for that reason. 
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1. Introduction 


In this thesis we present two unique algorithms that solve the mutual 
exclusion problem and we prove that the algorithms operate correctly. The 
mutual exclusion problem is typified by a situation in which there is some 
critical resource that will not work correctly if it is accessed simultaneously 
- by multiple processes. For example the critical resource might be a. 
data-base; if two processes were to modify the data-base at the same time the 
resulting information could very well be inconsistent. The function of a 
mutual exclusion algorithm is to coordinate the several processes involved 
so that no two of them will ever access the resource concurrently. | Also, 
mutual exclusion. algorithms are usually required to be fair meaning that 
all processes that try to access the resource will be allowed to do so 
eventually. That is, the algorithm must not be able to lock out some or — 
all of the processes indefinitely. _ Both algorithms that we present are 
fair. a : 

Mutual exclusion algorithms block the attempts of processes to enter 
the critical resource while the resource is being referenced by a previous 
process. The algorithms that we present here are called busywaiting 
algorithms. This means that when some process that wishes to enter the: 
critical resource is blocked -- i.e. when the process must be prevented 
from proceeding because the resource is busy -- the process waits in a loop 


testing the value of some memory location. This is in contrast to devices 


| such as semaphores [Dijkstra, 1968] or serializers [Hewitt ,. 1975) that block 
PEOEE SSeS: by suppending their activation. . 
The First algorithm that we present uses simple cells of read/write 
memory as its synchronization primitive. The only instructions: that these 
‘cells are assumed to implement are update instructions and read-contents 
instructions. The algorithm is modelled after the classical ones by 
Dijkstra [Dijkstra, 1965] and Knuth [Knuth, 1966] in that'it requires an 
array of memory cells proportional in size to: the number of processes in the 
system. Unlike the previous work, our algorithm generalizes so as to: apply 
to systems where the number of processes may grow unboundedly over time. 
We prove the correctness of our algorithm using the actor model of 
computation. | - 
The second mutual exclusion algorithm that we study uses an extended 
type of cell as the syrachronization primitive; the cells are extended so as 
to model read/modify/write type instructions that are commonplace in real 
computers. It is well known how to implement unfair mutual exclusion with 
read/modify/write instructions: this is the standard test-and-set loop on 
a binary lock variable. We show how the unfair algorithm can be extended 
to be fair and how the algorithm may be used in systems with an increasing 
number of processes. 
We shall, in the rest of the Introduction, review the basic elements | 
of the actor made That section primarily is intended to introduce the 
syntax and basic definitions we will use in the chests, and to amplify those 


elements of the model that are most relevant here. 


he 


Chapter 2 presents the cell-based algorithm and a formal proof of its 
correctness. Chapter 3 studies the extended-cell solution and informally 


proves that it works properly. 


1.1 Basic Elements 


The actor model of computation as used:dn this thesis originated with 
Carl Hewitt [Hewitt, 1973]; many theoretical issues of the model were 
extensively developed by.-Irene Greif im her reaceat dissertation [Greif, 4975]. 

Every computational. entity in an acter syetem.és an acter. There is. 
no distinction drawn between data and precedures -- both are actors. 
Information is passed between actors by an operation called message trans- 
mission, which is rather analogous to argument passing and returning in 
conventional systems. It should be noted.thet mestaas transmission" does 


not refer to any sort of inter~pr 


cess communicatian; there is only one 

locus ef contre] ina message transmission and it-flows wi th the message. form 
‘source to target. As actors. are the only entities :in ‘an actor system, and 

- since they interact solely by means of message transmissions, therefore 

message transmissions are the only activities. ‘that-can take place in.an. 


actor system. Message transmissions are called events. 


An actor is defined in terms..of the messages it accepts and the. 
messages it generates. in response. Most acters accept only a narrow class. 
of messages: the addition actor, for example, accepts messages containing _ 


a sequence of numbers only; a list actor accepts messages such as ‘first’, 


ze. 


‘rest', and 'cons'; and so forth. If an actor receives a message it | 
doesn't like, it is expected to send an error-nessage to a Special actor 
called the complaints see We shan't deal with errors or complaints — 
in any detail in this thesis. 7 

When an actor receives an acceptable message it may generate a very 
large number of events as a result of this stimulus.* Usually we are not 
interested in specifying all. the messages seat in response; since message 
transmissions are the only activities that occur amongst actors, a specification 
of all messages would require specifying the entire actor down to the Tevel 
of avinitives, Instead we just specify a sub-set of the events generated 
by the actor. The common strategy for suppressing unwanted. detail is to 
ignore most messa@ transmissions, except those whose targets are of interest. 
Greif calls the set of interesting target actors the "distinguished set". 
Input/output specifications correspond to a distinguished set containing 
(1) the actor being called and (2) the actor expected to receive the output. 


A specification coacerned with side-effects. might have all cells be in the 


* We will see later that in some sense the actor generates the entire future 
of the process. Here we mean the more limited set of messages obtained by 
regarding the actor as analogous to a called sub-procedure. 


distinguished set. And so forth. 

Consider as an example of actor specification, the addition actor. 
We wish to convey that plus accepts messages containing two numbers and 
returns their sum as its answer. The specification starts with the message 
received by plus, and then states what messages result: 


Event 1: plus receives a message containing nl and n2, . 
where nl and n2 are both numbers. 


Event 2: ? receives a message containing nl + n2 
_ There is a question-mark in event 2 because we have not stated 

anywhere the identity of the actor which is to receive the answer. In most 
programming languages there is an implictt control structure that governs 
what happens to the results of expressions. Typically, if an expression 
like (+ 2 3) were embedded in another expression, e.g. (f (+ 2 3)), then the 
result of (+ 2 3) is implicitly caused to be the argument to f. ‘In the 
actor model, such control structure is not implicitly present; if one Wishes 
to receive an answer to a message an explicit continuation actor must be 
‘present in the message. The activity whereby an actor "returns a value” 
reduces to just another case of message transmission -- namely sending a. 
message containing the value to the continuation actor. 

The plus actor must be defined so as to require that a continuation 
actor is present in the original message: 

If there is an event in the history of the form 


event 1: plus receives a message containing n] and n2 
where nl and n2 are both numbers, and 
a continuation, called cont 
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then there is an event of the form. 

event 2: cont receives a.message containing. n] + n2. 

This specification is at a high level and says nothing about how plus. 
does its job. The actor may use the hardware add. instruction in some cases: 
and multiple precision string addition in other cases, or whatever. There 
may be many, many events. between event 1 and event 2, the specification 
leaves al] that unspecified. But if event 1] apes t happen then event 2 
will happen. | 

This latter interpretation of the actor definition. is most important. 
The relationship between event 1 and event 2 is called the actor causality : 
relationship: we say, event 1 causes event 2. “The "how" of this. causality : 
is not specified -- merely that if event 1 happens, then that causes event 2 
to happen later. : } 

The generalness of the causal link is reflected.in the.form of the 
event statements. Event 2 is the activity of plus answering the caller. 
Intuitively this event might be described ke. "plus sends nl+n2 to cont"; 
however, the way the event actually described there is.ne mention of plus 
at all. This is because plus may have delegated the job of sending the 
answer to some sub-actor or acquaintance. In a model where control is fully 
nested -- e.g. in LISP a3 the answer would have to be passed back up from. the 
sub-procedure through plus on its slay out to the original caller. However, 
in the actor model the control structure is represented explicitly in message 
continuations; plus could very easily tell the sub-actor to generate the 


answer and send it directly to the original ‘continuation. 
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As it happens, this non-nesting of control occurs commonly in actor 
definitions. Strictly speaking, a single actor may never generate more 
than one message in any given process. If the computation at hand requires 
that several messages be sent -- as in a program of sequential statements 
or a nested expression ~- a whole slew of subsiatary: actors are created, one 
for each message transmission. The final actor created will typically 
be specified to send the answer to the original calter. No multi-processing 
is implied by this plethora of actor creation; it is mostly a device for 
simplifying the formal notation. It also helps avotd problems with the 
values of local variables. Each actor is born with the values of other 
actors "frozen in" in a manner similar to tie programing. language POP-2 
[Burstall, Collins, Popplestone, 1971], and so there is no need for such 
things as stack frames as formal devices, et al. | : 

The only case in which the originally*¢atted actor is the one that 
actually sends the result back happens if’ the actor dues no visible 
computation The actor cannot even do ary*run-time argument type chécking. 
Such an actor must always be a primitives primitive actors, however, can be 
of this form and actually do useful things. — | 

Events are the basic computational units in the setor model and we 
shall refer to them repeatedly. A more convenient syntax for events is 
desirable therefore. Events will usually be wrtttea’ in the following 
format: | 


< target receives message [in activator ]* > 


*This field is optional, it will be used in multi-process cases. 


-9- 


The format of a message is 


(message:, sequence-of-arguments 
(reply-to: continuation) ) 


For example, the event of calling plus with the arguments 2 and 3 
would be written | are 
event 1: < plus receives (message: [2 3] 
(reply-to: cont)) > 
and plus's response would be | ae 
event 2: < cont. receives (message: [5]) > 
As we have defined them, actors are devices that map an event into a 
sequence of events: they. map the event whereby they are called into the | 
sequence of message transmissions they cause. “An ordered. sequence of. events 
is called a behavior. The sequence of events. caused’ by an actor ‘is called 
the actor's behavior. 7 : 
If an event corresponds to a procedure call -- i.e. it is of the form 
event 1: Spracedine receives (message: [--arguments--] 
a ' (reply-to:. return-pt)) >, 
then it will cause many events but eventually, hopefully, there will be an - 
event: | | 
event n: < return-pt receives, (message: [--result of procedure--])> 
Of course, return-pt is itself an actor and it will map event n into some 


subsequent events n+], nt2, ... 


10 


For example, consider the following program fragment: 


factorial (5) ; 
print ('done') ; 


The call to procedure factorial corresponds to the event 
event 1: < factorial receives (message: [5] 


(reply-to: return-pt)) >. 


Factorial will do many things internally, Sut assuming it is a well-defined 
function, it will eventually return to the continuation, return-pt. That 
event would be: 
event n: <return-pt receives (apply:[--countdown's value--])> 
~ Now, what does the actor return-pt do? factorial has just finished 
and the next thing the program text says to do is "print (‘done’);". 
Furthermore, the program says to do that no matter what factorial did. The 
actor return-pt must be defined as follows: - 
event 1: < return-pt receives ? > 
| causes | 
event 2: < print receives (message: ['done'] 
(reply-to: return-pt-2))>. 
The question mark in event 1 means that return-pt cares not what its input 


is; it does the same thing no matter what. The continuation in event 2 must 


Aye 


be an actor like return-pt that performs the step after print (‘done’) in the 
program.. | | Bg eR 
Plugging return-pt's specification into the’ program = at 
the following scenario: 
event 1: <factorial receives (message: [5] 


(reply-to: return-pt))> 


event n: <return-pt receives (message: [--factorial' s valion--T)> 
event n+l: ‘<print receives (message: [*done' ] 


(reply-to: return-pt-2))> 


The dot-dot-dot after event n+} reflects the fact that program noone on. going. 

Print will cause many events, eventual ly return- -pt- ~2 will receive a message 

and it will cause the next step of the program to be run, etc. Ta paraphrase 

an old homily, event n+] is the first event of the rest of the program's life. 
It seems intuitively appealing to break the behavior between events n 

and ntl. All the events between 1 and n inclusive. are reasonably 

attributable to factorial; they may reasonably ‘be called "Factorial's behavior". 

The events from n+] onward are more naturally called “the rest of the program". 
This division of behavior is quite useful in many cases. It allows 


us to talk of an actor's behavior, or the behavior resulting from an event, 
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in a compact and more or less precise way*. We will use this natural 
terminology often. It is important to note, though, that the division is 
really arbitrary. The events n and n+] have no locally observable 
characteristics that distinguish them from the events before or the events 
after. | 

If we decide, therefore, not to break the behavior between events n 
and ntl, a different interpretation emerges. The behavior resulting from 
an event may be regarded as all the future behavior of the process. This 
view interprets behaviors as more than descriptors of the past performance 
of an actor system; behaviors are also prescriptors of the future of the 
system. | 
| Almost all actors are pure in the sense that their behavior does not 
vary of time. Given the same input message at two different times, the | 
actor will cause the same sequence of "next" events both times. If all 
actors in the system were pure there could never be ay time varying behavior 
in the system -- everytime the system were started up it would inevitably 


produce the same answer in the same way. ‘There is only one primitive actor 


*It is quite hard to make the notion formally precise, though. What is the 
resulting behavior of an event without a continuation? Even if there is a 
continuation, we have.no assurance that a message will ever be sent.to the 
continuation. 
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whose behavior is not fixed over time and that is the. cell of read/write 
storage. | | 

Cells are defined to respond to two kinds of messages: one massage 
of the form (message: ['contents?'] (reply-to: continuation)) and the other 
message (message: ['update' to new-value] (reply-to: continuation)). The: 
first message asks the cell for its contents and the.cel] responds by sending 
back the value stored in the most recent update message. The event-eatiowiad 
a 'contents?' query will always be of the form — 

Eel] 'Sscontents: <continuation receives (message :[celi's-contents})>. 
However the actual content of the event will vary. as the contents of the cell 
varies. | ; . 

Whenever the behavior resulting from an event is time varying that 
means a side-effect has occurred. By localizing all side-effects to the 
actions of one particular kind of actor, the cell, reasoning about the time | 
variability of behaviors is greatly simplified. Of:course, since. actors may 
be defined by users that utilize arbitrary numbers of cells in arbitrary 
algorithms, no generality is lost through the simplification. 

We have noted that the past behavior of a system. together with all the 
actor definitions in the system prescribe the future course of that system.* 
Suppose we have an actor system, A, which has been running for a while. A 


will, therefore, have a behavior B. As long as the actor system is running 


* Though if there is parallelism, there may be many possible future courses. 
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its behavior will continue to grow. If we were to “freeze” the actor 

system at a point in time, the behavior would of course stop expanding and 
would have a last event, E64: In order to resumé the ‘computation, all 

we need is E),.;> becatise the behavior that YesuTts from Fast | ds all the 
future behavior of the process as described ‘above. 

Behaviors are the concrete realization of processes in the actor model, 

“analogous to such things as ‘stack frames in more convent tonal models of 
computation. Consider the mode] suggested by Bébrow and Weigbreit [Bobrow | 

& Weigbreit, 1974] for instance. As a process runs it maintains a push-down 
stack of stack frames each of which includes a program counter, local : 
variable bindings and all the control structure information necessary for the 
~ running’ procedure to Feferetice non-Tocal variables and’ to return to its 
caller. To freeze a process in the Bobrow and Wetgbrett model we would stop 
it: after some program step. The Stack frame for the ‘punning procedure and - 
all its predecessors on the stack are at that point poised, ready to “execute 
the next step in the program.* ~All that is ean iedenars = les 

All models of computation need ‘some method to ‘cbiGretely incarnate * 

running processes. In the Bobrow and Weigbreit model, thé stack and most 
particularly the ‘current" stack franes play that rote In the actor model, it 
* In the model the program counter is assumed to be updated after each 


program step. For a real running system the stack frames only simulate 
the model and usually don't update the PC after each instruction.. 
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is behaviors and their last event. 
The actor model of computation is largely ‘wotivated by an “interest 
in describing systems of multiple processes. The model as developed so 
far here has dealt only with Single process systems, though. The formal 
machinery developed for the single process case must be “extended ever so 
slightly to embrace multiple processes. _— 
Behaviors are the concrete realization of processes in the actor mode}. 
For each process in the actor system there will be a distinct behavior 
describing its activities since creation. The union of all the individual 
behaviors is also called a ‘behavior: it is the ‘behavior of the actor system 
as a whole. If the processes never interact ‘then that is the ‘end of the 
story. If, however, the processes do interact ‘then we need a | Tittle more | 
formal machinery. | | | | a 
| If two processes interact we often want to compare. an event or events 
in the behavior of one process with events. in the behavior of the other. 
In order to tell which events go with which process, all events are labelled | 
with a name called an ‘activator. The activator is. ‘more or less equivalent toa 
process name. | 
Events that include an activator are written 
event: <target receives message in activator> : 
Our nomenclature for activators will normally be a possibly with a subscript, 
Phrases Mike; “event E, in data- peat will be used as a shorthand for 


"event E, in the behavior of the process whose activator is a data-base". 
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Multiple process systems may be implemented in numerous configurations: 
all the processes may actually run on the same computer with only simulated 
parallelism; or each process may have its own processor; or some may be one 
way and some the other way. We wish for our theory, at least in its 
fundamental form, to be applicable to all forms of parallel processes 
independent of how the parallel ism is achieved. We make no assumptions 
therefore about the relative speeds of various components of the system. One 

component. might be a human. being performing instructions off a written sheet 
and another component might be an 1BM 370/168. The human being might have 
an effective execution speed of one instruction per second as jeomeared to the 
machine’ Ss 60 million instructions per second. 

Also there may be arbitrary and uneven delays between cuenta even in the 
same process. We may have an algorithm part of which executes on the 
370/168 ‘and part of which requires human processing. | “Though the algorithm 
represents one single sequence of steps -- i. e. it ig is a single precess). -- 
some events therein are separated by 160 nanoseconds while others are 2 spaced 
a second apart. 

Nor do we assume the existence . of a global time standard with which 
activities may be time-stamped. Global time- -stamping of events that 
transpire in separate processes is feasible. for locally executing processes 
but is often hard to achieve with geographically distributed systems. At a 
minimum, the existence of a common time standard for all Bracesses requires 


careful planning ahead, both to acquire the common Alecks and to make sure 
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-all programs use the time information. properly. There. are some problems 
where global Cin Stamp ifas seen an invaluable aid and others where it adds 
as many difficulties as it solves.* At this time’we' are interested: in seeing 
how far asynchronous, non-time based models can go. 

The impact of these assumptions is that events in separate processes 
‘are not usually comparable -- i.e. it is not usually possible to tel] which 
event happened first. Concretely, the impact of these assumptions is that 
in general, between any two events. in. one process there may occur arbitrary: 


numbers of events in other processes. 


* Satellite ALOHA networds are a positive example of time-stamping. 
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2. Busywaiting Synchronization Algorithms Using Cells. 


We shal] study in this chapter the problem of: enforcing mutual exclusion 
of an arbitrary number of processes with respect to. some particular critical 
or protected actor. The mutual exclusion problem has been investigated 
exhaustively in the literature. Generally work in this area may be classified 
according to the primitive synchronization. facilities that are assumed to be 
available. In this context the phrasé “primitive facility" means that the 
operation involved occurs indivisibly, as if it were a.single instruction or 

‘micro-instruction in the instruction set of a hardware machine. 

Naturally the more sophisticated the primitives are that are assumed 
to exist, the easier it is to solve the mutual exclusion problem and related 
problems such as the readers/writers problem. Some common synchronization 
primitives include semaphores [Dijkstra, 1968], monitors [Hoane, 1974], and 

_ serializers [Hewitt, 1975]. These primitives all achieve mutual exclusion 
of arbitrary numbers of processes. 

Cells may also be used as the synchronization primitive of a mutual 
exclusion algorithm as is well neue: Dijkstra [Dijkstra, 1965] and Knuth 
[Knuth, 1966] developed the classic algorithms along these lines. Their 
algorithms only work, though, if the number of processes in the system does 
not increase over time beyond a fixed maximum; it remains unproved whether 
mutual exclusion of an arbitrary number of processes, where the number is not 


fixed over time, can be achieved using célls. We will prove that it can be 
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accomp1] ished. . 

We have elected to study mutual exclustén per se because it fs the — 
fundamental synchronization activity needed to: protect actors from harmful 
multi-process corcurrency. Using a mutual exclusfon operator as a. building 
block, other more sophisticated actor protectten mechantsins caf easily be. 

built. These more sophisticated mechanisms may impTement better scheduling. 
_al gorithms than are possible in the simple mutual -éxcluston operator; alsd 
they may be able to recognize situations where total mutual exclusion of 
processes is overly restrictive, .and they: may allow some class of processes 
to access the protected actor collection concurrently.” This latter elab- 
oration.corresponds to the well-known readers/writers problem and its 
extensions. | | © 4g | 3 , 

In the..following section we-describe the algorithm and demonstrate 
informally that it works correctly. A formal proof in the actor model is 


presented in the section. following. 


2.1 The array of cells solution 


The algorithm that we present here is based on the. approach proposed. 
by Dijkstra in [Dijkstra, 1965]. The key ingredient of this approach is 
that the mutual exclusion operator maintains an array of cells that must be 
at least as large as the number of processes that use the operator. . Each 


element of the array is indexed by the "name" of a process. 
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The basic form of the Knuth and Dijkstra algorithms is this: When a 
process wishes to pass through the mutual exclusion guardian it changes the 
value of its entry in the cell array to indicate to all other processes that 
it wants to get through. Then some computation: #5 performed on every other 
entry in the array; the actual computation varies from algorithm to algorithm, 
but in all cases the purpose of the computation is to indicate whether or not 
there is another process already executing inside ‘the critical region. Only 
if this predicate answers that no processes are in the critical region may 
the current process proceed to pass through the guardian. If the new process. 
is not permitted to enter the critical region now -- j.e. if the computation 
it performed on the array said, MNo!" ~~ the process must wait. It does so 
by looping, each time computing the entrance: predicate-unti} the answer is 
"Yes!", ye | 

Algorithms that follow this approach have been proven correct by 
previous researchers. In particular, Greif [Greif, 1975] has proven that 
a similar algorithm proposed by Knuth (Knuth, 1966] indeed does work. 
Correctness of mutual exclusion algorithms has two components: First, it 
must be the case that two processes never execute in the critical region 
concurrently -- this is a minimum specification; and second, the algorithm 
must be fair -- i.e. it must be guaranteed that al] processes that attempt 
to pass through the guardian will make it through eventually. 

The algorithm of Knuth is known to work, but only if the number of. 


processes in the system does not exceed the size of the array of cells. 


ee 


We will show how this limitation can be circumvented, thus proving that fair 
mutual exclusion can be achieved for an arbitrary number of processes using 
cells as the primitives. fess 

The original atgorithms presented by Dijkstra: and Knuth are pretty 
complicated. ‘The atgorithm we describe here is similar to theirs in 
essence, but it is much easier to understand, and mich easter to reason about. 
First we present the simple case of the algorithm where the number: of processes 
is assumed to remain fixed. ~ Then we will ‘extend ‘the approach to handle 
‘arbitrary numbers of processes. : 


Consider the illustrative diagrain below: 


an array of cells, 
state-array 


protected-actor - 
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We will call the array of cells required by the algorithm, state-array; we call 
the actor Sein. protacead: protected-actor. Also, we assume the presence of 
a special process, Outer? whose job it is to mind the store. Whenever an 

external process Oss wishes to access the protected-actor, it changes the value 


of state-array [i] and then waits. in its idle mode loops continually 


Amutex 
scanning the state-array; eventually Certax will note the changed value of 
state-array [i], and inform a. that it may enter the protected-actor. This 
algorithm is intended to be fair and we will prove that it is, though by no 
_ means is it FIFO. This means that while all processes that try to pass through 
the mutual exclusion device are assured of getting through, no attempt is made 
to service requests in the order they are made. 

The operation of the device is regulated by the value in state-array. 
Each element of state-array reflects the state of one process in its efforts 


to get through the guardian. The elements of state-array range over four 


values: 


idle -- a. does not wish to enter; 
request -- a. requests permission to enter protected-actor; 


grant -- O. is granted permission to enter protected-actor; 


done -- o. has finished its interaction; 
and idle, again, indicating that the interaction is complete from ere point 


f vi 
of view and Onutex's 


any state value to the next is always in the province of either a; or ae 


viewpoint, too. It is important that the transition from 


but never both. The transitions are controlled as follows: 
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idle to request -- by Oe when it decides to enters - 
request to grant -- by mutex. when it allows a. fo enter; 
grant to done -- by Oy when it has finished with protected-actor; 


done to idle -- ed Oy es it notices that a. As done. 


mu tex 


Each external process mist foTiow an’ estabttshed sei aites dealings 
with the protected-actor. The mutual. exclusion operator can. only. be. assured 
of working properly if the protocol is adhered. to dutifully, every time the 
protected-actor is referenced. In. order to. localize the implementation of. ets 
protocol, we will utilize the encant of "e encasen ement" put forward by Greif : 
[Greif, 1975] and Hewitt [Hewitt, 1974]. 
We will imagine that the actor being protected is fully enclosed, 

encased, within another actor that serves as ‘an alias for it. All other actors 
know only the alias; they do not know the protected-actor itself. Whenever. 
an actor wishes to send a message to the erotectadcactor, it sends it instead 
to the alias-protécted-actor; the alias observes the protocol, and retransmits 
the message to its ward when’ the protocol allows it. Alias-protected-actor | 
is spectfied by the algorithm written descriptively HeTow bie aor is 
specified formally in LISP shortly hereafter): ; 

alias-protected-actor = 

(1) recetve argument, and call it pies 

(3) update state-array [i]: = ‘request! 


(4) loop waiting for state-array [i] to be 'grant', as follows 
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(5) ask state-array ri) 4 for its contents, and let state = the contents 
(6) there are two cases for state: 3 
_ (6-1) state = ‘request’ -- repeat from step (4) 2 
(6-2) state = 'grant' -- proceed with step (7). 


(7). send message (message: the- ~input-message (reply-to: step -(8)-below)) 
to protected-actor 


(8) when finished referencing protected-actor, update State-array [i]:='done' 
(9) loop waiting for state-array [i] to be ‘ide’, as follows 
(10) ask state-array [i] for its contents, and let Statens the contents 
(11) there are two cases for state: | 
(11-1) state = ‘done! -- repeat from step (9) 


(11-2) state = ‘idle’ -- exit to externally supplied continuation 
with answer received. from. protected-actor in step (8). 


END: 


The storekeeper process, a mutes? follows a different regimen. Onutex 
may be thought of as running in two modes, a scan.mode and a wait mode. In 
the scan mode, Onutex circulates through the state-array scanning each element 
in turn. When it reads a state-array[i] whose value is 'request', it stops 
its scan. It changes the element, state-array[i] to be ‘grant’, and enters 
its wait mode. In wait mode, Snater loops testing the same element of the 
array over and over. When that element becomes 'done', Onutex changes it | 


back to ‘idle’, and resumes Scanning. Importantly, Onutex always resumes 
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its scan with the array element after state-array[1]. 

The algorithm that a, 4., executes is embod ied in the actor described 
below, an actor that we call regulate-mutual-exclusion. Steps (2), (3), (9), _ 
(10), and (11) comprise the scan mode of the algorithm; steps (14) - (18) 
implement the wait mode. (This Ketoe is specified formally in LISP following 
the description). | : | ne | a | 


regulate-mutual-exclusion = 
(1) set cell i:= first process name known | 
(2) ask state-array[i] for its contents, and set state . contents 
(3) there are two cases for state: eee, 
(3-1) state = ‘idle’ -- go to end of Toop, step (9), to continue scan 
(3-2) state = 'request' -- proceed with step (4) 
(4) update state-array[i]:= + ‘grant’ 
(5) loop waiting for state-array[i] to be ‘done’, as follows » 
(6) ask state-array[i] for its contents, and set state = contents 
(7) there are two cases for state: 
(7-1) state = 'grant' -- repeat from step (5) 
(7-2) state = 'done' -- proceed with step (8) 
(8) update state-array[i];= ‘idle’ | 
(9) resume or continue scanning the state-array as follows 
(10) there are two cases for the process name index, 7: 


(10-1) i = last process name known -- update i:= first process 
name. known 


296s 


(10-2) else, update i:= next process name after i 
(11) repeat from step (2). 


END 


The two actors alias-protected-actor and regulate-mutual-exclusion 
specified formally in a LISP-like notation on the following pages. A 
certain license with LISP syntax is taken in that we write array references 
in the ALGOL-ish form 

array [index] 
rather than the LISP 
(get ‘array index) 


and (store ‘array index value). 
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(defun alias-protected-actor (the-input-message) 


(prog (i state answer) 


Step-2 (setq i (the-name-of-the-process)) 

_ Step-3 (set state-array[i] 'request') . 
Step-4 33; loop waiting for state-array[i] ta be -'grant' 
Step-5 (setq state state-array[i] 

Step-6 (cond . | = ; 
Step-6-1 ({equal state 'request') (goto step-4)) 
Step-6-2  ((equal state ‘grant') (goto. step-7)) 

. (else (error)) | | eae hy 
Step-7 (setq answer (protected-actor .the-input-message)) 
Step-8 (set state-array[i] 'done') | 
Step-9 3; loop waiting for state-array[i] to be ‘idle’ 
Step-10 (setq state state-array[i]) - 

Step-11 (cond . . sn) Rie et 

Step-11-1 ((equal. state 'done') (goto step-9)) 

Step-11-2 ((equal state ‘idle'). (return -answer)) 
(else (error))))) 
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(defun regulate-mutual-exclusion nil 
(prog (i state) 
Step-1 (setq i (first-process-name-known) ) 
Step-2 (setq state state-array[1]) — 
Step-3 (cond 
Step-3-1 ((equal state ‘idle'}(goto step-4)) 
(else (error))) 
Step-4 (set state-array[i] 'grant') . 
Step-5 3; loop waiting for state-array[f] to ‘be ‘done’ 
“Step-6 (setq state state-array[1}) 
Step-7 (cond 
Step-7-1 ({equal state ‘grant')(goto step-5)) 
Step-7-2 ((equal state ‘done’ ) (goto ‘step-8)) 
(else (errory)) 
Step-8 . (set statecarraylt) ‘idle') 
Step-9 3; resume or continue scanning the state-array 
Step-10 (cond 
Step-10-1 — ({equal- i (last-process-name=known) ) 
(setq i (first-process-name-known))) 
Step-10-2 (else (setq i (next-process-name-after i)))) 


Step-11 (goto step-2))) 


-29- 


The proper operation of this machanisn is apparent assuming that 
the system starts out in its “natural” initial condition. | That is; all 
entries of the state-array must be initialized to 'idie! $ no external process 
may be referencing protected-actor initially, and Spite, must start. eng 
regulate-mutual-exclusion at step (1). “We shat explain the ‘correctness of 
this solution informally at this pine: a forma] proof is s presented in the 
next section. ae ee 

There are two aspects to the correct operation of” a fair mutual 
exclusion operator. First, does ue ever implenent mutual exclusion -- a? e. 
does it prevent the simultaneous access of ‘two processes to the protected- 
actor. The second aspect is the fairness of the devices will every process 
that attempts to reference the protected-actor be allowed to ‘do so eventually. 

We will ‘demonstrate First that the systen here does ‘indeed achieve a 
mutual exclusion. Proceeding Frei the stated. initial conditions, it is 
clear that no process; will ever barerench ‘the protected-actor unless alias- 
“protected first sees the state- ~array element equal to ‘grant. Also, after . 
| the process is done, and not before, al ias-protected-actor changes the ‘grant! 
state to ‘done’. Thus if no other actor ever modifies a “state-array element 
that equals ‘grant’, we may be sure that no ) process will access the protected- 
actor unless its state array element is ‘grant’. we 

Furthermore, each process that wishes to enter ‘the protected region first 
sets its state element to be ‘request! and does not set it to be ‘grant’. | 
The anly actor that does set states to ‘grant! is the actor regulate-mutual - 


exclusion, that actor will only set one state to ‘grant! and no more until 
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that state- ~array element cycles to ‘done’ first. It Follows that no more 
than one state-array element will equal ‘grant concurrently and, therefore, 
that no more than one process wil] reference protected-actor concurrently. 

. Fairness of the operator may be inferred from the scan algorithm 
employed, assuming that the operations in step (10) ‘of regulate-mutual -exclusion 
are all well defined, one-to-one functions. That is, ‘there Tust be a unique 
first process name, a unique last process nies and the function next applied 
iteratively starting with the first name must yield all the names known to the 
system exactly once. Given all this, ‘it is clear that if no process ever 
requests entry then each state-array eTenent will be Scanned once before any 
element is scanne’ twice. | : 

If one ‘process sets its state- warray element to ‘request ' regulate-mutual - 
exclusion will note the fact the next time that element. is scanned. The 
ceannenGn will then be interrupted and steps (4) - (8) attempted, and the 
state-array element will be set ‘to ‘grant! ; The specification of alias-pro- 
tected- actor makes it clear that once state-array[t]_ is set to ‘request’ s the 
entire sequence of the protocol must inevitably occur. Thus it is a foregone 
conclusion that the state element will eventually ‘becore ‘done’. Regulate- 
mutual-exclusion detects the ‘done’ state and resets it to 'idle' thus 
completing the cycle. | 

The important fact is that the entire. interlude from step (4) to 
step (8) does not affect the scan parameter, i. Thus providing that all the 
steps (4) - (8) do occur the scan will resume as if there had been no inter- 


ruption. And as we have noted, the interaction between the two processes 


coeds Blea A OR eee 


ae 


does insure the completion of those steps. TRUS. tex will scan all the 
ather elements of state-array before it, scans: the.ane just Tet through . 
again, Therefore all the elements of the array will -get-a “next! shot . - 
through to the protected-actar and none can be locked out, I.e. the operator 
is fair. | 

This algorithm for mutual exclusion only works so long as the number 


of processes that may wish to access the protected-actor does not exceed 
the size of the state-array. Of course, nothing in either alias-protected-_ 


actor nor regulate-mutual-exclusion prohibits the use of a variable size 

structure in place of an actual fixed size array. Suppose State-array were 
physically implemented as a list. Whenever a new process sought to join the 
crowd of processes with rights to the mutual exclusion operator, a new entry 

could be cons'ed onto the front of the state-array list, and the variable pointing 
to the front of the list could be updated to include the new entry. 

In this model the identifier "state-array" will be used to name the list 
of state-array elements. The notation -- siatecainayrid -- must be understood 
asa symbolically indexed reference into the list pointed at by state-array. 

We may continue to assume that the expression state-array[i] returns a pointer 
to the cell that the ith process must twiddle in order to pass through the 
mutual-exclusion operator; therefore the statements like 

(set state-array[i] 'request') 
that appear in the actor alias-protected-actor will stil] work Bven though 


state-array is changed to a list. 
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The algorithm for regulate-mutual-exclusion though references all the 
entries of state-array sequentially and it is more convenient to rewrite that 
actor using car's and cdr's than it is to try to make the array notation 
work. A version of regulate-mutual-exclusion that is particularized for 


the case of state-array being a list is presented on the following page: 
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(defun regulate-mutual-exclusion nil 
(prog (i-state state) 
(setq i-state state-array) 
Step-2 (setq state (car i-state)) 
(cond o: 
. ((equal state ‘idle')(goto step-9)) 
((equal state. 'request'} (goto. stepeA)) 
| (else (error)}e; 0 vee 8 xshee 
Step-4 (rplaca i-staté 'grant') i 
33 loop waiting for state-arrayl], i 2. i- -state, to be done" 
Step-6 (setq state (car i-state)) ae 
(cond 
((equal state ‘grant’ )(goto step-6)) 
((equal state oe J (goto step-8)) 
(else (error)) | | 
Step-8 - (rplaca i-state ‘idle') 
3; resume or continue scanning the state-array 
Step-9 (cond ; if at end of state-array Vist 
({nul1 (cdr i- sstate)) 3 then reset, Anstate ‘to. beginning 
(setq i-state state-array):-. 
(else (setq i-state (cdr i-state)))) 
> else set i-state to next-entry 


(goto step-2))) 
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The operation of epeaeide a new process may add the new process ia the 
state-array by cons'ing a cell for the new process onto $tate-array. This 
procedure is described in algorithms for actors fork and expand-state-array 
below: 


fork = 
(1) receive argument and call it new-process 


(2) do whatever has to be done in the: innards of the system to create 
a new process - 


(3) expand- -state-array for the new- -process lees betow) 
(4) exit to externally supplied cont inuat ion 
END 


expand-state-array = 
(1) | receive argument and call it new-process 


(2) allocate a new cell and call it new-state. Update new-state's 
initial contents to be ‘idle’ , 


(3) Cons new-state onto state-array and: Tet new-state-array = the 
returned value 


(4) store new-state in the bowels of the system in a manner associated 
with new-process 


(5) -update state-array:= new-state-array 

(6) exit 

‘END : 
The actor expand-state-array is expressed formalty in LISP on the 


following page: 
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(defun expand-state-array (new-process)} 
(prog (new-state new-state-array) 
Step-2 (setq new-state ‘idle') 
Step-3 (setq new-state-array (cons. new-state state-areay)) 
Step-4 (... store new-state in, the system...) . 


Step-5 (setq state-array new-state-array))) 


There is a potential timing | error associated with the actor expand-state- 
array if it is executed concurrently by multiple processes. A possible 


behavior involving two concurrent executions of PEne actor is illustrated below: 


Process-1. : Provess-2 . 
(2} snaaess take = ‘idle’ (2) new-state := ‘idle’ 
(3) new-state-array := (3)"new-state-array := 
(cons new-state state- array)| : (cons new-state state-array) 
a ae  .. 


(5). state-array. := noucstarecatead (5) ‘state-array := new-state-array 
That is, both processes could create the new-staté-array using the — 


same previous state-array resulting in a structure like 
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state-array 


new-state~array for 


Ae 


new-state-array 
for 
process-2 


Whichever process updates state-array in step (5) last is the one that 

will win out in the end. Its new-state cel] will be included in the 
state-array list; the other entry, while not. garbage nor possessing a dangling 
reference, will never be referenceable from state-array. 

This bug would be avoided, however, if the operation of adding processes 
to state-array were a mutually exclusive operation. There would be no problem 
with extending the state-array list to arbitrary size, if only the operation 
were restricted to one process at a time. In the actor model, new processes 


do not arise through spontaneous generation; aside from the processes that are 
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stipulated as existing in the system's initial conditions, all other’ 
processes are created. by events. Events, of course, are activities in some 
process that already exists. 7 | 

If we assume that. al] initial processes are represented in the 
state-array then we may specify that process creation occurs in a mutually 
exclusive manner by protecting the actor fork with precisely the mutual 
exclusion operator that we have described here. That is we may define 
an actor alias-fork that is identical to alias-protected-actor, except it 
relays the input messages to fork instead of protected-actor. In other 
words we may use state-array to protect the actor that expands statecarray! ” 

There is one other trouble-spot in extending the “array of cells" 
solution to arbitrary number of processes -- the processes being added to 
the staté-array may be very prolific and may themselves create more new — 
processes. These additional new processes will have to be added to the 
State-array, too, of course. And they too may be very prolific. . 

_ Suppose that when new processes are added to state-array that they are 
added at the end. And suppose that when each passes through to the protected 
region it creates a new process that jimediately-attempts ‘ta pass through - 
the mutual exclusion operator itself. ‘Under these conditions, the scan may 
be stuck in an infinitely growing morass of fast breeding processes. Any 
requests entered closer to the beginning of the array would never be served. 

This bug may be avoided, though, by the ciple strategen’ of extending 
the array at its front. Now, even though the array might grow without bound 


over time, every request that is entered would be scanned and allowed through 
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eventually. This is because no process created during one scan of the | 
state-array would itself be attended unti? the next scan. 

Thus, the "array of cells" solution to the muteal exclusion problem may 
be extended to handle the most general case of unbounded numbers of processes. 


2.2 Formal proof of the solution 


We shall prove. the correctness of the algorithm in two stages. First, 
we will prove that mutual exclusion per se is implemented; then we will prove 
the fairness of the algorithm. For the first part it doesn't matter whether 
or not the number of processes remains constant. The extension to handle 
arbitrary numbers of processes need only be considered ‘in the fairness proof. 


Before proceeding, let us state precisely what is. being proved, 


Definition: a normal returning actor 
Let protected-actor be an actor which includes in its specifications 
the following fact: if the event : . 


Eanter-i: Sirotes cedsacecy pece!ves 7 
(message: any-message 
(reply-to: continuation) ) in a,> 
appears in the behavior then the event 


sa ees ; : . 
Eoxit-i continuation vere 1 ves: 


(message: any-answer) in a> 


will appear later in the behavior. 
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Then protected-actor will be called a’ normal returning actor. 
This first definition ensures that the actors being protected are all 
wel] -behaved and act like normal sub-routines.. If we send a message to the 


protected-actor we expect it to answer and not fly off on its own someplace. 


Definition: mutually exclusive reference. -. 
Let protected-actor be a normal returning actor. 


Then protected-actor is said to be referenced in a mutually exclusive 


fashion if and only if for all mean ley events 


(E E > E 


enter-i’ “exit-i’ enter-j.”. le 
one of the following two order ings holds | nage 
te Q) E before E xit-i before E , before fae j 


enter-i_ enter Jj 


or = (2) Exntoy-j Defore E,.i4_; before Eenter- before Eat, ; 


Definition: fair encasement . 

Let protected-actor be a normal returning actor. "And let alias-protected- 
actor be another actor. | | | ve i 

Alias-protected-actor fairly encases pretectad-actor if and only if . 
a behavior has the following event in it: } 

Enel lo- 5° <al ias-protected-actor receives 
(message: any message oe Bh 
“(reply- to: continuation) 4 in a,> 


Then it also has the following events in the stated order: 
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E anter-i: <protected-actor receives 
(message: any-message | 
(reply-to:: alias-continuation)) in a> 
Eaxit-i: <alias-continuation receives 
(message: any-answer) in a.>. 
| Ebyebye-i' <continuation receives 


(message: any-answer) in ,>. 


Definition: fair mutual exclusion actor 


Let protected-actor and a alias-protetted-actor be actors and Suppose 
that a Bilas biaces tecc actor eptely encases protected-actor. 
Then alias-protected actor is a fair mutual exe laston actor for 


protected-actor if and only if for all histories which contain 


E on eig IE E 


hello-i” “enter-i? “exit-i” 
iAj 


E E.. 


| Fbyebye- -i’ Enello-i” enter-j’ 
Eexit-J? os Ebyebye-j 


one of the following two orderings holds: 
either (1) ene F 


or (2) Enter -j ‘before era _; before ~ before Tee 4 


before Eo vit before Centers -j before before E exit-j 


before £ 


exit-j’ 
In particular Bnese orderings hold even a ’ Enel to- -j -were between Fhetlo- 4 


and Ebyebye- 4 or the converse. 
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The theorem we shal] prove is this: 


Theorem: “Given the actor a alias-protected actor as specified in Section 
2.1 above and any actor protected-actor which satisfies the constaints in the 
definition here. Also, given the actor r requlate-mutual-exclusion and the 
process Cutex as specified in section 2.1 

Suppose that the Oe system starts out in the. ‘following initial 


conditions: 


(1) each element of state-array equals ‘idle’; 


(2) .no event of the ee E has yet occurred; 


enter- -i 
(3) Onitex has not yet begun ‘to execute regulate-muitual -exclusion, but 
it will execute the actor from the beginning once ‘the system is started up. 


Then, alias potec ted actor 4s a fair meal exclusion actor for : 
protected-actor. aon 


The proof of this theorem will be facilitated by the concept of an 
"inter-process handshake" describing the interaction between the external 
process and Onutex: The actors a al ias-protected-actor and regulate-mutual- 
exclusion interact by means of a protocal with the following character: | 
one process sets the cell, state-arrayli], to some particular state value 
and then busywaits until state- arrayl#] changes to pone other value. The 
thee process meanwhile is already set to Took for a particular value in 
state-array[i]; when it sees that value it "shakes hands" with the first 


process by causing the next transition of state-array[i]. In this way the 
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two processes carat each other's act IVICtES and jead each other through 
the algorithm in a step-by-step sequential manner. 

In the following sub-section we will formalize the concept of inter- 
process handshaking. After that the mutual exclusion algorithm will be 
reformulated in terms of handshakes and we will use the reformulated Version 


to prove the main theorem. 


2.2.1 Handshaking between processes 


| The concept of handshaking will be defined by. specifying an actor that 
_ implements it. Then we prove several useful theorems regarding the properties 
“% of handshake actors. 


The actor handshake receives messages of the form 


(message: (shake: cell 
(set-to: value-1) 
(then-wait: value 2)) 
| (reply-to: continuation) ). 
handshake will update the cell to value-1 then loop busywaiting until the 
cell's contents become value-2. At that time, handshake replies to the 
continuation. — The algorithm for handshake is described below. A formal 


version of the actor in LISP follows it.. 


Handshake = 
(1) receive input message of the form 
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(message: (shake: cel] 
| (set-to: value-1) 
(then-wait: value-2)) 
(reply-to: continuation) ) 
(2) update the contents of the cell to value-1. 
(3) busywait for ‘the contents of the cel? to become value-2 as follows: 
(4) read contents of cell and let ‘state = the contents. 
(5) there are two cases for state: 
(5-1) state = value-2 -- repeat from step (3); 
- (5-2) state = value-2 -- proceed with step (6). 
(6) exit to the continuation 


END. 


The actor is specified formally below: 
(defun handshake (Sshake-cel? value-1 value-2) 
(prog (state) 
Step-2 (setq shake-cell value-1) 
Step-4 (setq state shake-cel1) 
Step-5 (cond ((not (equal state value-2)){goto step-4))))) 


Definition: completion of a handshake. . 
A handshake is completed when a reply to the continuation occurs. That 


is, given the event 
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Enandshake-1-2: “handshake receives 
(message: (shake: cell 
- (set-to: value-1) 
(then-wait: value-2) )} 
{reply-to;. continuation-1))in a,>. 
Enandshake-1-2 is completed by the next. event. if any,-.of the form 


E <continuation-1 receives, 


complete-1-2° 
(message: 2) in a> . 


Definition: matching a handshake 


Let EF andshake-1-2 D& an event of the form 


<handshake receives 
(message: (shake: cell 
(set-to: value-1) - 
(then-wait: value-2)) 
(reply-to: continuation~1)) in. a,>. 


Let E be an event of the: form. 


update-2 
<cell receives 
(message: ['update' to value-2] 


(reply-to ?)) in o>. 


Then E pdate-2 is said to match the handshake Ey spe1-2° 
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The reader should note:that matching of handshakes is purely a 
syntactic matter. The matching event is not in any sense guaranteed to 
satisfy the ees in the handshake and thus lead to the completion 
of the handshake; indeed an event that matches a handshake may even occur 


before the handshake! 


Definition: completion-causing event of a handshake 
Given Ehandshake-1-2 as in the previous definitions, and given an 


event Eupdate-2 that matches Ehandshake-1-2° 
Consider the event 


<cell receives 
(message: [‘update’ to value-1] 

(reply-to: step (3) of handshake) ) in a,> 
occurring after E,. ushake-1-2 but before the reply to continuation-1; call 
this event E Set-to-1° | 

Consider the class of events 
<cell receives | . 
(message: ['contents?'] | 
(reply-to: step (4) of handshake)) in On? 
also occurring after EL. acnake-1-2 but before its completion. Call these 


events EV ait-for-2° 
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be any event of: the form oe 


Rk Eclobber 


Elobber® <cell receives a 
(message: ic update’ to not-value-1) 


(repty-to: 2)) in Oy? 


Where not-value- i = value-1. 


The event Eupdate- 2 4s a complet ton-causing event of emai: 1-2 
if and only if E update-2 appears in the behavior after Ehandshake-1-2° and 
no event of the form Ej... is between €, urdate-2 ‘and the next occurrence 


of Eait-for-2° ; 


Theorem: Completion- causing event causes completion of a handshake 
(This theorem expresses the fact that ‘conpletion-causing’ ‘évents 
are aptly named ; that a. handshake will complete if and omy if 
a completion-causing event is present. oe 
Given an event E,, achake-1-2 28 above and any event  Eupdate-2 
that is a completion-causing event of Eniidstubected” 
Then Enandshake- 1-2 will be completed - -- i.e. handshake will reply 
to the continuation -- if and ae if some event * Evpaate -2 fs present in 
the behavior. -_ : - 
Proof: This result follows directly Winn os algorithm for 
handshake and the axioms for cells. Handshake wil] reply to the continuation 


in step (6) of the algorithm if and only if it read the contents of the cell 
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Via an event of the form E ait-for- 


From the axioms of the cell we see that this condition requires 


9 and found the contents to be value-2. 


that the most recent update event. in the target ordering of the cel] must 


be of the form Eupdate-2° 
A simple but important corollary of this theorem applies. when the 
"set-to" value does not equal the "then-wait" value of a handshake. © First 


we define a bit of terminology. 


Definition: proper handshakes 
Let Enandshake-1-2 be a handshake event as above of the form — 


Ehandshake-1-2' “handshake receives 
(message: (shake: cell 
(set~to: value-1) 
. (then-wait: vajue-2)) 
7 (veply-to: continuation)) in a > 
Enandshake-1-2 15 called a proper handshake if. and only if value-1 


# value-2. 


Corollary: completion causing event of a proper handshake 
Let Enandshake be a proper handshake event in Gy, 
Then no completion causing event of Enandshake °@" be an event in Gp,» also. 


Proof: All completion causing events of Enandshake must be events that 
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update its cell between E,,.4.,.,, and the completion of the handshake; also 
the event must update the cell to value-2. 

The only event in the handshake that updates the cell is the "set-to:" 
event therein and that event updates the cell to vatue-1. Since value-1 
# value-2, the "set-to:" event cannot. be a completion causing event of the 
handshake. © And since no events occur ina, other ‘than events that pertain 
to the handshake until its completion, no events tha, can cause the 
completion. | 2 . 

The property expressed by the corollary is important because it ensures 
that proper handshakes do cause the running process to wait for some specified 
events in another process. Hereafter we shall assume that all handshakes 
are proper. eee oa 
| Another interesting property of handshakes is that they may be chained 
one after the other resulting in a multi-process sequencing of events as we 
will see shortly. First we need to make definitions similar te the ones 
above but involving inter-process handshaking instead of simple updating 


of events. 


Definition: a_matching handshake . 
Let Ey ndshake-1-2 De an evene of the form 


Enandshake-1-2: <handshake receives 
| (message: (shake: cell 
(set-to: value-1) 
- (thenswait: value-2)) 


-(reply-to: continuation-1)) in a> 
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Let Ey andshake-2-3 De an event of the form 


<handshake receives 
| (message: (shake: cel] 
(set-to: value-2) 
(then-to: value-3)) 
(reply-to: cont must fon-2)) in a>. 
Then, E handshake-2-3 js said ‘to be a patching handshake for Fhandshake- 1-2" 


| ii inte Siig iia 

Given Enandshake-1-2 4nd Enandshake-2-3 25 if the previous definition. 
set-to-3 and bwait-for- | 
definition of a completion causing event of a handshake. And tet E acbber 


Let E 2 be events related to Ep andshake-1-2 25 in the - 


be any event that updates the cell to a value not equal to value-2. 


Then, Enandshake-2- 3 is a completion-causing handshake of Fe pas 
if and only if the following conditions hotd: 


O) Enandshake-2-3 is after ESet-to-1 and pe tone the completion of 


Ehandshake-1-2° 


and (2) There are no events £ between: E: 1 “and the completion d 


clobber ‘set: -to- 


of “handshake-1-2 


_ Theorem : conpletion-causing handshakes cause. completion - 
Given an event Ehandshake - 1-2 48 above and let Etandshat2- 3 be any 
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completion causing handshake of EL andshake-1-2 


Suppose also that there is no other event E 9 of the form 


update- 


Eupdate-2° <cell receives 


(message: ['update' to value-2] 
(reply-to: ?)) in Co> 
between the event E. 4 45.] (related to FE, anape-j-2 a8 in the previous 
definitions) and the completion of Ey. 4 cpape-2-3° 
Then, Enandshake-1-2 Will be completed -- i.e. handshake will reply 
to the continuation -- if and only if some event EL gcnapa-2-3 appears in 


the behavior. 


Proof: Let E represent the class of events between each Enandshake-2-3 


set-to-2 
jand its completion wherein the cell is updated to value-2. 


I.e. each E is of the form 


set-to-2 


E Set-to-2: <cell receives 


(message: ['update' to value-2] 


(reply-to: step (3) of handshake))in a>. 


By supposition the events E.., 45.9 are the only events between EF... _4,_, and 


the completion of ae ere that update cell to any value whatsoever. Not 


all tne events E need occur in the range between E£ ] and the 


set-to-2 
completion but any that do are completion causing events of Eandshake-1-2? and 


set-to- 


thus fulfill the "if" part of the theorem. 


—=5T- 


The "only if" part follows — the observation that those ESet- to-2_ 
events that are completion causing events of Fhandshake- Pr 2 are its ony 
completion causing events. —_ | 

A useful corollary to the above theorem applies. to chains of 
completion causing handshakes. Given a sequence of handshake events where 
each handshake but the first causes the completion of its predecessor; if 
the first handshake does in fact occur, then all of the handshakes except 
the Jast one will complete one by one in sequence. | Though the handshakes 
appear in separate processes it is as if there were an activator type causal 


Tink between them. 


Definition: chains of completion-causing handshakes — 
Let Enandshake-1-2? “handshake-2-3? "handshake»3=4* **** "handshake-n-m 
each be handshake events. Let Ehandshake-1-2* Fhandshake-3-4" --. be events. 


in process a, and let the others be in process Oh: a, # Oy: Suppose further 


that E . in the 


handshake-1-2 is before Puandeliake: 3-4 is before Ecieletaee” 6” 


oO, activator ordering and that the events of a, are ordered similarly. 


Let Fhandshake- 9.3 be a completion-causing handshake of Enandshake- 1-2? 
let Enandshake-3 -4 be a completion causing handshake of Eaadchala: 2-3: etc. 

Finally assume that there are no events updating the handshake cell other 
the "set-to:" events in the handshakes , between Enandshake-1-2 274 the event 


E >» where E 


set-to-n 'set-to-n 


is the "set-to:" event in Ey. dchake-n-m’ 
Then, the sequence of events Enandshake-1-2° Enandshake~2-3° handshake-3-4° 


: EHanashakechon is called a chain of completion-causing handshakes. 
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-& Corollary: chain of complet ion-causing handshakes 

Given a chain of completion-causing handshakes Fords hahe-t-t" 
Enindstikect 9-4, Pianeta nae | 3 , 

Then each of the handshakes but the ast one. will contahe in sequence . 

-- 1-8. Enandshake-1-2 "11] complete befpre Enanashate-2-3 Which will 
it will start. | 
Proof: This corollary follows from successive spoticat tnd of the previous: 
theorem that states that completion causing handshakes cause colipletion. 

In general, given a chain of completion causing handshakes occurring 
in activators a, and Ops there may ‘be many ‘events. between ‘the completion of 
one handshake in one process and the start of the:next handshake tn that 
same process. For example, suppose a, ; Oantribution to a handshake chain 
includes the events Cafidshake-1. 1- 2 and rasa 3-4" These ‘twe: events | 
are part of a larger piece of a, ts peel thet A130 includes ‘the following 
events and relationships: 

Enandshake- 1-2 before the comptetfon of “aeicuive 1-2 
before an arbitrary. sequence ‘of events 
before Ehandshake-3-4° 

Let's cal] the handshake event. in ay, that Tinks Ehandshake-1-2 to 

Enandshake-3-4 in. the chain, En sidchekeco2a! “An important fact is that the 


“arbitrary sequence of events an Dg eked eeere only oeeurs between E, sndshake-2-3 
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and its completion. The handshaking causes the arbitrary events in a, to be 
placed in a time envelope demarked by Thandshake-2 2 3 and its completion. 


This relationship is illustrated below: 


E arbitrary 


handshake set-to wait-for C sequence | Enandshake set-to 
1-2 1 2 of events 3-4 3 
a ee a + mmr » Sane teer eae: ——— ° > wee oe ay 


Enandshake set-fo 


2-3 ca, A = 
time of 

arbitrary 
sequence. 
of events 


mae envelope demarked by ae Re ee ce 


bptilmecs 


The dashed lines represent the busywait loops present in the handshake actor. 
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Definition: inter-handshake gap 


Let Enandshake-1-2° Fhandshake-2-3” handshake-3-4? a ae 


E be a chain of completion causirig handshakes in processes 


handshake-m-n? 
a, and a,. Suppose that events E, 4 pakenT-2° ENandshake-3-4,° . . are 
the events ina,. | 

We will represent a general pair of successive handshake events in 


either process by the notation 


Enandshake-i-j> Ehandshake-k-1 
where if we continue to use the subscript convention followed so far, i,j,k,_ 


and 1 are successive integers. 

Let us cal] the completion event of Ehandshake-1-j° Chandshake-i-j. 

Then the sequence of events in the activator ordéring of Chandshake-i-j? 
after that event and before the event Enandshake-k-1 15 called the inter-handshake 
gap between j and k; that sequence will be-denoted gap-j-k. 

The first event of gap-j-k -- i.e. the very next event in the activator | 


ordering following C -- is called E 


handshake-i-j gap-j-ke The last event of : 
the gap -- i.e. the event preceeding E,. gchake-k-1 ~~ 15 called the completion — 


event of the gap and will be written Coap-d-k" 
Definition: parallel inter-handshake gaps and handshakes 


Let Enandshake-1-2° Enandshake-2-3? Enandshake-3-4? a ea Enandshake-m-n 
be a chain of completion causing handshakes. Let gap-2-3, gap-3-4, .. ., 


gap-(m-1)-m be the corresponding inter-handshake gaps. 
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Then we will say that the pairs (Epsndshake-3-4° gap-3-4) vie oy 


(E are each parallel inter-handshake gaps 


handshake-(m-1)-m, gap-(m-1)-m) 
and gaps. 
Theorem: the envelopment of inter-handshake gaps 
Let Enandshake-1-2? Fhandshake-2-37°'** Fhandshake-m-n D@ @ chain of 
completion causing handshakes. Let.gap-2-3, gap-3-4,..., gap-(m-1)-m be 
the corresponding inter-handshake gaps. | 
Then for any inter-handshake gap, gap-j-k, and its parallel handshake 
Enandshake-j-k? the following relationsips hold: 


Enandshake-j-k before ESap-3-k 
before C.45-5-1 before Chandshake-J-k" 
Of in other words, the gap is enveloped in a time perfod demarked by its 
parallel handshake. . 
Proof: It follows from the definition of inter-handshake gaps that 
Chandshake-i-d, dees pea7 the completion event of the handshake preceeding 
the gap -- is before E 


And similarly C is before the first 


gap-j-k° gap-j-k 
event of the next handshake, Enandshake-h-1, T= kel. He, shall ‘prove the 


theorem by proving that 


Enandshake~j-k ts before Chatidshake~i-J 


and Enandshake-k-1 |5 before Chandshake-j-k 


which yields the overall]? relationship 
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Enandshake-j-k P°fre Chanashake-i-j PefOre Egan. 5 


before Coap-j-k before E)  ndshake-h-1 before Cy. ndshake-j-k 


Enandshake -j-k 1S Fefore Chandshake-i-j Pec@us® Enandshake-j-k 'S 3 
completion-causing handshake -of Eh andshake-i-j. Furthermore, Enandshake-t-J 
may not complete before Enandshake-j-k SCS by virtue of the "chain of 
completion-causing handshakes" corollary. 7 

Similarly Enandshake-k-1 18 before Changshake-j-k PeCUSe Enandshake-k-1 
is the completion~causing -handshake of En andshake«J-k° 


The two results of most relevance to us here are these: 

(1) If we can establish that two processes interact as a chain of 
completion-causing handshakes, then the tnter-process interaction once begun 
will complete up to the last handshake. - If. the last handshake can be 
completed, also, through some separate mechanism then the entire interaction 
will complete. . 

(2) The events in one process's inter-handshake gaps will always be 


enclosed timewise in a handshake in the other process. 


2.2.2 Reformulation of the algorithm using handshakes 

In this section we will restate the algorithms that constitute the 
actors alias-protected-actor and. regulate-mutual-exclusion replacing the 
explicit busywaiting loops in those algorithms by invocations of the . 
handshake actor. We will prove that the interactions of those two actors 
does take the form of a chain of completion-causing handshakes and therefore 
the major theorems of the previous section do apply to these acters. 


The reformulated algorithms are presented below. The equivalence of 
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the original algorithms to these revised ones is apparent by even a textual 
substitution of the body of the handshake actor for each call to it. As 
usual we first present an informal description followed by a formal speci- 


fication in LISP. 


alias-protected-actor = (revised) © : | 
(1) receive argument and call it the-input-message. 
(2) set local identifier 1 = the name of the process. 


(3) send handshake the message 


(message: (shake: state-array [i] - 
| (set-to: 'request') 
(then-wait: ‘grant')) | 
(reply-to: step (4))). 
(4) send protected-actor the message 
(message: the-input-message 
(reply-to: step (5)).. 
(5) send handshake the message | 
(message: (shake: state-array [1] 
(set-to: 'done') Me 
(then-wait: "idle')). 
(reply-to: step (6))). 
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(6) exit to external continuation with the answer received from 
protected-actor in step (4). | | 
END 


regulate-mutual-exclusion = (revised) 
(1) set cell i:= first process name known. . 
(2) ask state-array[i] for its contents and let state = contents. 
(3) thre are two cases for state: 


(3-1) state = ‘idle’ -- go to end of loop, step (6), to 
continue scan's — i 


(3-2) state = 'request' -- proceed with step’ (4). 
(4) send handshake the message | 
3" (message: (shake: state-array [i] 
(set-to: 'grant') 
(then-wait: 'done')) 
(reply-to: step (5)}). 
(5) update state-array [i]:= ‘idle’... 
(6) resume or continue scanning the state-array as follows: 
_ (7) there are two cases for the process name index, 7: 


| (7-1) i = last process name known -- update i:= first process 
name known; 


(7-2) else, update i:= next process name after i. 
(8) repeat from step (2). | 
END | 


-59- 


(defun al ias-protected-actor (the- input-message) - ; revised _ 


(prog (i answer) — 


Step-2 (setq i (the-process-name) 
Step-3 | (handshake State-array[i] © ‘request’ ‘grant! ) Ce 
Step-4 (setq answer (protected-actor the- ‘nput-nessage)) 
Step-5 (handshake state-array[1] ‘done’ idle’ ) 
| Step-6 (return answer ) ) ) | | . 
(defun Pegi) aterm tual “exe lus 10 nil “jrevised 
(prog (i state) | 
~ Step-1 (setq i (first- process-name-known) ) 
Step-2 (setq state state-array[i]) 
Step-3 (cond 
Step-3-1 ((equal state 'idle') (goto step-6)) © 
Step-3-2 ((equal state ‘request') (goto step+4)) 
(elise (error) ) 
Step-4 (handshake state-array[1] ‘grant’ ‘done*) 
Step-5 (set state-array[i] ‘idle*') : 
. Step-6 = resume or continue scanning the state-drray © 
Step-7 (cond : 
| Step-7-1 ((equal { (last-process-name-known) )° 
(setq i (first-process-namé-known))) 
Step-7-2 (else (setq i (next-process-name-after i)))) 
Step-8 (goto step-2))) 
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In order to use our actor/behavioral proof techniques to prove properties 
of these programs we aie first establish some corelation between steps in 
the algorithms and events in the behavior of the systen that results ‘when 
the programs are executed. This corelation is somewhat compl icated by the 
repetitive character of the programs; we may expect ‘that a process will 
attempt to enter the protected-actor many times during its execution and so 
each program step will be executed many times even for one particular process. 

Each program ctan generates a class of events all ‘of very similar form. 
For example each time the alias- -protected-actor receives : a esas -- step (1) 


of the algorithm -- an event of the “form ie 


<alias-protected-actor receives 
(message: the-input-message deh: 
(reply-to: continuation)) in o,> 

occurs. We will find it useful to classify events beth-by the program step 
to which they correspond and by the value-of the: index i applicable to that 
step. Thus the above event might be classified-as: “an event resulting from 
step (1) in alias-protected-actor with index =i"... We shall adopt a more 
succinct and mneumonic nomenclature along those lines. Events corelated 


with steps in alias- ~protected-actor: will. be denoted by E where 


subscript-i’ 
the subscript will have some mneufnonic appeal; events resulting from 


regulate-mutual-exclusion will be written M (the "M" is to remind 


dubscr Ipt- = 
us that regulate-mutual-exclusion is rua bY Onstex only)... 
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We remind the reader that appelations such as E me 


subscript-i ™ 
classes of similar events, But where no confusion is likely to result 
we shall use the same symbol to refer to specific events; when we must 

refer to more than one event of a class, we will differentiate the names 
‘With primes, e.g. E subscript-i° 


Definition: names of events resulting from the algorithms 
*Let Enello-i denote the events whereby alfas-protected actor receives 
an input message: 
Enello-j° <alias-protected-actor receives 
(message: the-input-message 


(reply-to: continuation)) in a> 


*Let ELequest-1 be the handshake event at step (3) of the actor: 
Enequest-i: <handshake receives | 
(message: (shake: state-array[i] 
| (set-to: 'request') 
(then-wait: ‘grant')) 
(reply-to: step (4))) in a>. 
*Let Ceeand name the events whereby the-input-message is relayed to 


the protected-actor. E is the first event that references the 


: enter-i 
critical protected-actor 


E <protected-actor receives — 


enter-i' — 
(message: the-input-message 


(reply-to: step (5))) in a>. 
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‘*Let Eo i¢_; denote events of protected-actor replying to the alias. 


E :<step (5) of alias- protected-actor receives 


exit-i 
(message: the-answer) in a>. 


*Let E be the handshake event at step (5): 


done-i 


Esone-i: <handshake receives 


(message: (shake: state-arrayli] . 

(set-to: ‘done'). 

(then-wait: 'idle')) . 

(reply-to: step.(6}}) in a,>. 
~*And tet EDyebye-i denote the events whereby alias-protected-actor 
transmits protected-actor's:- answer to the outside world: 


Ebyebye-1* <continuation receives — 


(message: the-answer) in a,>. 
Now we define events in regulate-mutual-exclusion. 


*Let M eric 4 be the event in step (2) that scans state-arrayLi]. 


M : <state-array[i] receives 


scan-i* 
(message: [‘contents?'] 


(reply-to: step (2))) in o,446,?- 


*The avant following M 


eeane a takes two possible: forms. Let’ 


Mnot-request- - be the response 


M 


Net -request-t: <step (2) of regulate-mutual-exclusion receives 


- (message: ‘idie') ina, pay 23 
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let M F be the other response 


request- 


Mrequest-t° Sstep (2) of regulate-mutual-exclusion receives 


(message: "request ) ina “mutex” vo 
*Let Morant-1 be the handshake event at step (4): 
M-orant-i" <handshake receives | 
(message: (shake: ‘state-array[i]_ 
af (set- to: ‘grant’ a | 
(then-wait: ‘done! y) 
(reply-to: ‘step (5))) an Oey tex? 
*Let Midte- ; denote events at step (5) that reset the element to ‘idle’. 


Mrale- 7 cstate-array[t] + receives | 
(message: ['update' to. idle’ 7 ; 
(reply-to: step. (6))) in as . 


A significant ordering relationship among’ the framed: events: of 
alias-protected-actor may be: inferred from the straight-line, non-branching 
nature of the actor’s algorithm. Since there are no. branches in. the 
algorithm at the level of abstraction represented by the revised version ~ 
here, if all the named events. occur, they must occur: in order. 

Theorem: straight line thedrem for alias-protected-actor - 

Given the event class names defined above. 7 


We may structure the event classes in an ordered sequence: 


[Esra E E 
hello-i request-t? enter, Fede i’ ee Fnsite ge 


If an event From any class appears in an actor aot. s behavior 
then an event from each of the preceeding classes in the sequence must also | 
appear, in ‘the same order’ as the events appear in the sequence. For example, 


if an event E appears ina system’ s behavior, then the following 


byebye-i 
events must also appear, pe fore E vabye- oe in the stated order: 


Enello- ; before E 4 before Ea cae “i ‘before Fie. j before Euone- i" 


request- 7 
Furthermore, if two events of the =. named class, call them 


E and £' appear in the behavior, then an event of each other 


; and €' 


‘class-i class- i 


named class must appear between E. 


class- hea 


Proof: The order used for the sequence of events: is derived by inspection 


of the stated text of the algorithm used by ‘alias-protected-actor. 

The inviolability of the order ‘expressed in the theorem follows from 
the absence of loops and branches in the algorithm for alias-protected-actor 
at the level of abstraction pertaining to’ the. named: events. . 

A similar theorem may be derived for the events: ‘of regulate-mutual-_ 
exclusien, or at-least. the wait mode of the. algorithm; steps (2) through (5). 
With alias-protected-actor the theorem explained that the events pertaining 
to some particular: process, Oy» happen serially in-a well-defined sequence. 
Regulate-mutual-exclusion. differs in that it interacts with all the A 
external processes, not just one particular a,., But singe only one process 
ever runs the actor, the events therein pertaining. to all processes will occur 
serially. This is the property that is fundamentally depended on for the 


algorithm to provide mutual ‘exclusion. 
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Theorem: straight line theorem for regulate-mutual-exclusion’ 


Given the event class names defined above. 
And given the assumption that. Gnutex is the. only. process that ever 
executes the actor regulate-mutual-exclusion. . 


We may structure the following event classes in an.ordered sequence: - 


[Mrequest-i? \ grant-i’ Miate- jl: 
If an event from any of the classes appears in a- system! s behavior .. 


then an event from each of the preceeding glasses. An the seqienee st must also 
appear, in the same order as the. events appear ‘in ‘the ‘sequence. ae 
Furthermore, given two events ares q and E class-j?. where the word 
"class" may be instantiated by one 2 of “request”, a or "idle" -- if 


E 


class-i 2nd both appear in the behavior, ‘then at Teast the 


E 
_ class-j 
following other events must appear in order: 


(1) the events after E in the Sequence; 


class-i. 


(2) the events before E in the. “Sequence. 


For example, if the events Merenie Je and Marantz 5 


must also occur in that order. 


class-j 
both < occur then 


events Midle-a and M cquaih-e 


Proof: The fact that only one process ever executes. reguiatecmutyal-exclusion 
means that the behavior pertaining to it js a total order and the order of 
events may be read off the text of the actor's atgorithm: | 

The order is fixed and inviolable due to the absence of loops and 


M 


branches in that part of the algorithm giving use to M grant-i 


M 


request-i’ » and 


idle-i* 
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As a final result of this section we will prove that the two actors — 
interact as a chain of completion causing handshakes. There are three 
handshake events involved in any interaction between al4as-protected-actor 


E 


done-i> 4nd Morant-i' 


We will prove 


and regulate-mutual-exclusion -- they are E 
request-i’ Morant-i? "done-i' 
t-i always: causes the completion of 


Thus the 


; request-i° 
The chain that is formed in E 


that as used in these programs Moran 
Eequest-i and Edone-7 2!Ways causes the completion. of Monta 


three events form a chain of completion-causing handshakes. 


Theorem: causes completion of E 


grant-i request-i° 
Given the initial conditions stated for the main theorem, in particular 


the fact that state-array[i] is initialized to ‘idle’. 


Then M 


‘srant=1 is always. a completion-causing handshake of E 


request-1° 


Proof: From the definition, M 


grant-i isa completion causing handshake of 


E equest-i if and only if 


(1) M 
(2) Movant—i set-to-request-i? the event 


within the handshake that wpdates the cell to ‘request’; but ‘before the 


is a matching handshake for E 


grant-i request-~i° 


occurs after the event E 


completion of E 


request-i? 
and (3) there are no events Ej hi 4, between E+ -to-request-i and the 
complerion of ERequest-i7 “ere Ee jobber is an event of the form 
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E :< state- -array[t] receives. . 


clobber’ 
(message: ['update' to = 


(reply-to: ?)) in a, > ZF ‘grant’. 


The matching criterion is purely syntactic. - Two handshakes match if 


the "then-wait:" of one equals the "set-to:" of the other. EO waits 


request-i 


for state-array[i] = 'grant' and M sets staté-array[i] equal to 


grant-i 


‘grant’; hence M matches E 


grant-i request-i° 
The other two criteria are dependent on how the handshakes are sie in a 


specific program. Our then states that Ngrant 


+ and so.we must prove that in all 


must. always be a 


completion-causing handshake of. Evequest- 


executions of the actor system the proper orderings wil} hold: 


By the straight line theorem if M ‘appears in the behavior it 


grant-i 


must be preceeded by an event M is an event whereby 


request-i. Mequest-i 
state-array[i] reports that its contents equal ‘request’. The scan event, 


Mexane 2 that sends the ‘contents?' message to te atabiil ae must occur 


while state-array[{] equals ‘request’. | | a 
Since state-array[1] is initialized to 'tdte", Man ; in this situation — 


must occur after an update event that updates the cell to ‘request’, and 
before any event that resets: state-array[i] to any other value. A perusal 
of the algoritmmis here indicates that the only events ‘that ‘update state- array[i] 


to ‘request’ are the "set-to:" events in E “So the M. = giving 


request-i° scan- 
, u ra ot 
rise to an Mequest-i event may only occur after the set-to:" event in 


E -equest-i and. before the state is further updated . 
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The ordering information garnered so far is illustrated below: 


set-to 


Eequest-i request , ete Cc 


scan-1 request-i . -»  grant-i 


Now, we know that state-array[i] is not updated. in a handshake after the 


"set-to:" event; and once E-equest-i Completes the value. of the cell will no 


longer be 'request' and will not be reset to ‘request’ until another event of 
the E-equest-i class occurs. — Therefore, the Mocan-i leading to the Mrequest-i 
event may definitely be placed in time between the "set-to:" and the completion 


of aneE 


request-i ‘¥Pe event: 


ei AE tan! a ew cathe ad 


events within the handshake M 
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set—to C 


E equest- i request 


o> 4— - 


re .———> © —___-ye 


Ms can-4 ‘' “yequest-i - grant~i . 


Furthermore the handshake event. will not be completed until a completion- 


causing event of the form | 


<state-array[i] receives ; 
(message: ['update' to 'grant'] 
(reply-to; ?)) fn Oy > 


occurs. The only events of that form in the actor system are the "set-to:" , 


grant-i° We have therefore placed the time of 


M - and its "“set-to:" event as before the completion of E . also: 


grant-1 request-1 


270 


E set-to C 
request-i request 


set-to C 
grant 


a 
mutex 


Mscan-1 Mneq-i Morant-4 


So we see that M must always occur between an event of the form 


grant-i 


2 " ath:tt : ; 
Eset-to-request-i the "set-to:" event of a handshake, E 


and the completion of the handshake. Morant- 


2 of the definition of completion-causing handshakes. 


request-i 
3 thus always satisfies criterion 


The final point that we must establish is that no event, Eclobber? 


updating state-array[i] to value other than 'grant' may occur between 


E et-to-request=i 
to consider: 


and the completion of £ There are three cases 


request-i° 


clobber 15 4” event’ in a process other than a; OF Oo ays 


(2) that E lobber occurs in a5 


(1) that E 


or. (3) that E 


mutex 


lobhey happens ina 


ot a 


Case (1) may be rejected due to our supposition that only the: actors 
alias-protected-actor and regulate-mutual-exclusion are able to access: the 
State-array; alias-protected-actor makes it impossible for any process but 
a, to reference state-array[i]; and by assumption Onutex is the only process 
that ever runs regulate-mutual-exclusion. 

We have already noted that there are no update events in a handshake 
after the "set-to:" event. Therefore there are: ng cipaate. events in 5 


between E 4 and the completion of E 


set- teshaqieets request-i° 


As for Outex We have already proved that there are no events updating . 


state-array[i] between E After the occurrence of 


request-i nd M grant-i* 


the event M its "set-to:" event happens; this event updates the cell 


grant-i 
but it updates it to the allowed value, ‘grant’. Between the "set- to: " 


event and the completion of M i there are no events updating state-arrayLi] 


grant- 

so if E lobber occurs in Cate bis it must happen after the completion of Morant- i" 
But Morant- ; cannot complete until state-arrayli] 1 upgated Since 

that update does not happen ina... it must happen ina,. But we've 

just shewn that a, cannot update ‘state-arrayLi] further until Erequest- j 

completes. So. Tnutex cannot clobber the state until a, updates: it and a. 

cannot fies it until £ 


E 


request- -j completes. os e. ‘there can be no event 


in a. Pe to the completion of E 


clobber mutex 
is rejected also. 


request 2 Be and thus case (3) 


Having established that there can never be an event that clobbers the 


state~array element before E ts completed we have proved that the 


request- -j 


third and final criterion required for M 


grant-i to be a completion-causing 
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handshake of E 


request -t. 1S always satisfied.” Thts completes the proof 


of the theored. 


Theorem: Edone- ; causes completion of Morant- ae: 
Egone- ; is always a completion-caustng handshake of Ngrant- 4" 


Proof: The hes of this theoren is: simtlar to the proof of the previous 
theorem. 


Theorem: the handshakes form a chain of conpletion-causing handshakes. 
Given the actor el described in this aver ion and the stated initial 
conditions. 


M 


grant-i? & 


Then the sequence of events £ anes almeys forms 


request-1° © 
a chain of conpletion-causing handshakes. 
Proof: The previous | two theorens stated that 

(1) M 
and (2) E 


is always a complet fon-causing handshake of E 


grant-i request-i 


done? isa complet ion-causing handshake of Morant-i° 
The definition says that whenever these two relations hold then the events 
form a chain. Since the relatfons always hold in ‘this actor system, the. 


three events sivevs form a chain of completion-causing handshakes. 


2.2.3 Proving the theorem using handshakes 


In the previous section we proved that. the interaction between alias- 
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protected-actor and regulate-mutual-exclusfon always takes: the Form of a. 
chain of completion causing faiishakee: We shall five that result here to 
prove the main theorem of this chapter: that given the specified actor system 
and the specified initial conditions alias-protected-actor is a fair 
mutual exclusion actor for protected-actor. | 

The proof proceeds in two parts. The first part shows that all 
references to protected-actor that are funneled through alias-protected-actor 
occur in a mutually exclusive fashion. The second step is to prove that 
alias-protected-actor provides fair encasements of protected-actor. Combining 
these two points yields the overall theorem. 

We will see that Part I of the proof follows. straightforwardly from the 
handshake theorems developed fveection 2.2.1. Part II has two sub-parts 
one of which also follows from the handshake theorem; the second sub-part, 
though, involves proving the fairness of regulate-mutual -exclusion's scan 
algorithm. It is in this last part that the potential for more processes 
being added to the system must be accounted for. This last section does 
not follow from the handshake theorem. 
| Part I -- Given the actor system and initial conditions stipulated in the 
main theorem. | 

Then all references to protected-actor that occur within alias-protected- 


actor occur in a mutually exclusive fashion. 
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Proof: The definition of mutual -excTusion says the ‘following: 


Let Eenter- ; be an event of the form 
Eenter-i' <protected-actor + receives 
| (message: any-message 
(reply-to: continuation)) in a,> 
and let E, 34; be the next event thereafter of the form 
E 


exit-i: <continuation recedves 


(message: any-answer) in o,> 
Then for all quadruples of events 


(E 7° E »— 


enter-i* “exit-i Fenter-j” Fexit-d) uae ee 
one of the following tw orders must hold: 
either (1) E before Fexit- A before E 


or | (2) E oJ nadetie E 


before E_ 


enter- -i enter -j exit-j 


enter-i before E 


before E 


enter- “J exit exit-i° 


Given a pair of ‘events -- E seyeiias from the 


enter-i ths exit-i 
execution of alias-protected-actor, the. streight Vine ‘theorens for that 


actor shows that the events must accur between an event eequest- ; and the 
next event of the class Ey .4_;- Moreover Eanter-i 2d Ey apy must 


occur after the completion of E owhich is a handshake event. This 


request-4? 


means that E£ and E eccur ‘inthe interchandshake gap between 


enter-1 exit-i 


Enequest-i 294 Eqone-i 


We proved in the previous section that the sequence of handshakes 


E Morant-i? Edone-i 


request-i? is a chain of completion-causing handshakes. 


eae eae see oF 


‘ 4 
ey 
os; 
“ye 
if a 
La 
oer 
: 
pat 


ee eaten Wel 
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grant-i is the parallel handshake to the gap between 


Therefore, from. the envelopnent er inter-handshake 


It follows that M 


Erequest-i and Edone-i° 


w pee 
gaps theorem, we know that Mae “i “envelopes the gap ce e. Novant is 
before the completion of E equest- > and the completion a of Mgrant-i is- after 
Edone-i> And SINCE Eontey.g ANd Eoxieag, are WItHIN th 92D» Movant aj 
envelopes them too. See the illustration below: . 
Frequest=1 C Fenter-1 Eexit-4 Faone-1 e 
Os @ te ee ee ted ow oer 2 Sa DUETS Tyg AEE ot oh as eu . 
Qa... er to see tin nA pina iin en 
mutex | Mora cia 


critical | 
region 


—— = Morant-1'S envelope ae 


The straight-line theorem for the actor regulate-mutual-exclusion shows 


that if an event M appears in the behavior, then no other event of the 


grant-i 


class M . may appear until the completion of M appears. This 


grant-j 
leads to the following relationship: 


grant~i 
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Morant- 4 before E before E 


Morant- -i before Morant- -j 


for all values of i and j. 


exit-i spies Ta ema oF 


before E 


enter- i 


before E 


enter-j Eexitej” 


Embedded in that relationship is the relattonship required by the 
hypothesis, and thus Part I of the theorem is proved. 


Part II -- Given the actor system and initial conditions stipulated in the 
‘main theorem. Then alias-protected-actor. provides. fair encasement for 


protected-actor. 


Proof: There are two parts to the proof. First we will show that if a 
particular request is scanned then the associated message will be transmitted 
to protected-actor and the answer will subsequently be retransmitted to the 
external continuation. This part of the proof. is-essential ly a continuation 
of the previous proof of Part I.of the main theorem. ‘The second section 


of this proof establishes that the scanning of the array is itself fair. 


Part II-(a) -- Given the actor system and initial conditions stipulated in 
the main theorem. If an event of the form 
ENello-i: <alias-protected-actor receives 
(message: any-message 
(reply-to: continuation)) in as> 


appears in the behavior, and it is followed by an event of the form 
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M 


request-i' ater (2) of. regulate-autual-excTuston receives 


(message: ‘request ") in Sqytex , | 
then the following events ‘atso will appear in the behavior after 
Mpequest- ; and in the ‘stated order: | 

Moos <protected-actor receives 
. (message: any-message 
(reply-to: step (ayy) in CF > 
before 
Eaxitei: <steP (8) of aTias-protected-actor receives 
| | (message: any-answer) in a> oe 
aa before 


EDyebye- 24 :<continuation receives 


(message: any-answer) in %,>- 


Proof of Part II-(a): Certain parts of the hypothesis are true by inspection 


and are included here for completeness. In particular, if © j occurs, 


enter- 


then vexit- j is required to occur because protected-actor is constrained to be 


a norma] returning actor in. the hypothesis of the main theorem. 
If Enelo- ; occurs then by virtue of the straight line theorem the next 


named event, E i? is bound to happen. Also if M 


request occurs that 


“request - -j 


means that Mgrant- ; 


We proved in the previous section that the Sequence of: events: E 


will occur, too. 


“request-i 


and M form a completion causing chain of ‘handshakes and so 


gran a Fone -j 
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if Enequest-i? and Mgrant~i both occur, then Ey... 


after. But since E is the last handshake in.the chain it will] not 


will occur inevitably 


done-i 
become completed by virtue of activities in the chain; Eanes requires an 


explicit completion-causing event in order for that handshake to terminate 
and for the next step in alias-protected-actor to occur. By the same token 


if Edone-i completes then the next step of the program will happen, too; 


the step after the handshake is the step that replies to the external 
continuation -- i.e. it is the step corresponding to ELyebye-i° 
So if there will be a’ completion-causing event for Eaone-4 during every 


execution the system then the theorem is proved. 
The state of affairs in effect when EE, ; occurs is illustrated below. 


We know that M always completes after the "“set-to:" in Eyone-i because 


grant-i 


Edone-i is always a completion-causing handshake of Monant-i: 


set-to 


Eequest-1 : Fenter-i cv exit-i Eagone~i done 


a, we ee FO 9 8 0 ——————) oo - ~~ - 


a 
mutex e 


grant-1 erant 
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is M. 


The event ina mutex after the completion of M Nedleci: 


grant-i 


Ma aie-7 <state-array[i] receives 
(message: C update’ to ‘idle'] 
(reply-to: step (6))) in Suter? a 
We will prove. that Midle- i Ts always the one and onty completion- causing: 


event of Ey nei. 


idle-j must satisfy three criteria in order to completion-causing. 


event of Euone-i? 

(1) Midie- _; Must match Sisco - -- which it does -by inspection; | 

(2) Mi die- af must occur. after the "set- to: 0 “event related to. Ee © Gab 
which it does because Edone- i is always a complet ion-causing handshake of 
. Mgrant- i which is before Midle-i? 43 
and (3) there must be no other event updating state- -arrayLi] between Euone-i's 
"set-to:" event and the completion of Edone=t" This statement of the third 
criterion is stricter than the definition requires; if this statement proves to 
be true then Miaj,_; Will always be the one, and only completion-causing event 
of the handshake. | | ‘ 

The third criterion is true as follows: The only processes. that may 


reference state-arrayli] are and a st There is no update event. -between 


ex" 
the "set- to: "event of a handshake and its completion and so no event in a 
may violate the criterion. There are no more events jn Sn tex that update 
state-array[i] after Mi ale-i during this same cycle of the algorithm. If 


Onutex updates state-array[i] further, that update may not occur until after | 


We have already proved that events of the M cuect—i 


class handshake and therefore there 


4 
an event M request-i* 


class occur only during an Enequest-i 


; ; : 2 
must be an event E' between Midte-4 28d M 3; also if the 


request~j request-i 
alleged update event is to happen before the completion of Sone: 7? then 


E' request-i ™USt likewise occur before the completion of Eyi,._4- In other 


words the supposition that we are making is that there is an event E' quest-i 


between E and its completion. 


done-i 
The existence of such an event in that relationship leads to the 


yol lowing ores 


before E' before : ‘completion of Edone- i before EL yebye- ic 


Edone- -i request-i 
This ordering of events violates the straight line. theorem of aU lasc protected: 


actor. Hence there cannot be an event of the form E'. 


request- ; between E 


done~i 
and its completion and the third criteria is upheld. 


So M will always cause the ‘completion of E qs the event 


idle-i done- 


E is assured of occuring, and Part I1-(a) of the theorem is proved. 


byebye-i 
Now we must establish that the scanning of the array is itself done 

fairly. Part II-(a) showed that any request that does get scanned will 

get passed through to the protected-actor. Part - 1) shows that all 


requests that are made will be scanned. 


a II- (b) -- Given the actor system « and the initial conde ions stipulated 


in ‘the main theorem. If an event of the form 
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Eello-i* <alias-protected-actor receives 
(Message: any-message 


(reply-to: continuation) ) in ay? 


appears in the Sera then it will fae folTowe by an event. of the form 


M. : ssten (2) of regulate-mutual-exclusion receives 


request-i" 


(message: ‘request! ) in Cuter?” 


Also, if Enello- ; "happens and is followed by Mrequest- > then are 


request-i* unless there is 


will be no subsequent. event M* request-i- 


ancevent heros aftr FretTo-t 


Proof_of Part I1-(b): The second statement tin ‘the hypothes's is quite easy 
to establish and ms will dispose of it first. What ‘the statement is saying 
is that if a request is scanned énce $t- wi Ti-not- be ‘Scanned again. In other 
words the operation of letting a request into the protected-actor and passing 
the answer back out reinitializes the state-array element stmshow: 

We have already shown that if an event like Neequest-1 Occurs it must be 
immediately preceeded by an event M...,_4 that reads the.contents of 


state-array[i]. follows only if the contents of the state element 


Mrequest-i 


t t 
_were ‘request’. — If Mrequest 


and there cannot be another M,.,,_; type event in between. 


Miaye-¢? Of Course, sets state-arrayli] to be ‘idle’. There cannot be 


.q does happen then Miae 4 is assured of occurring 


another event of the Mrequest-i class until and unless state-array[i] is again 


made equal to 'request'. The only events in the system that do that are 
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E type events; E events in turn only occur after 


request-i request-i 


Enello-i's? and only one Epequest-i will fotlow any Enello~i without an 


intervening Enello-i 


So, what we have is this: 


in a,;: Enello-i before E 


j request-1 before E'neyio.4 before E' 


request-i 


request-i 


in mutex: Mrequest-i before Mi gye-; before M' 


which says that if E - must be 


request-i request-i 
-- i.e. the second statement is established. 


is before Mequest-i then E' 


before request-i 


The first statement in the hypothesis is stating that the scan of 


_ the array must be fair. Let Moo... be an event of the form 


M : <state-array[i] receives 


scan-i° 
(message: [‘contents?'] 
(reply-to: step (2)}) ina, ...>- 


The scan algorithm is fair if and only if for each process in the system there 


is a first scan event, M..,_;> and after each M..,_; event there is another one 
later. If those conditions hold then there will be an M...._; event after each 


event which implies that there will be an. M ; event after each 


Erequest-i request~- 
Enequest-i event also. Since each Eequest-i event is a direct result of the 
preceeding Fellow; event, this would mean that every E,.),,5_; would be 


followed by an M as required by the theoren. 


request-i 
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Events M occur ‘in. step(2). of 


Iscan- eo _ = 
value of i being scanned is: controlled by step(1):0 once: ond thereafter . 


by steps (6) and (7). Assume for the: moment: that the scan is not. interrupted 
by any request, and let’ S examine just. the scan. part of. the: algorithm regulate: 
mutual-exclusion = = (scan part only) 

(1) set cell i:= first process name known, o 

(2) ask state-array[i] for its contents and let state = contents. © 

(6) resume or continue scanning the sialon 8 

(7) there are two cases for the pracess:name index: 43° | . 

(7-1) i = last process. name. known odd “update. 5 ith first process ‘name mom. 
(7-2) else, update i:= next process name after j. | 
(8) repeat from step (2). 
END © 

If the state-array is static and does. nat change. Size with: time. ‘then the . 
first process name and the last process name are: ‘each constants. The scan 
algorithm then has the form. of. two nested loops: the euter leop repeatedly sets 
itoa constant initial value and the inner. Joop updates. 4 until it. reaches a 
constant maximum value. This structure wit]: result: in fair scanning if the 
function updating i has the following. property: starting with the first process 
name known, successive application of the function must yield all process names 
known to the system; tf the function is truly functional inthe mathematical 
sense then it will yield all process names once before returning any name a 


second time. 
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If the scan is interrupted then some event Moo; will lead to an 


M event rather than directly going to step (9). But as we have 


request-i — 


. already seen, if M. happens then 11 the’ Steps of the actor 


request-i 
reguiate-mutual-exclusion must: inevitably. énsue leading to Ms aye_; in step 
(5). After step (5), the scan is resumed in step (6). Since the wait 
mode interruption is guaranteed to terminate and to resume the scan, and 

since it does not effect the scan parameter fin any way. The interruption 
cannot modify the fairness of the scan algorithm. 

Our argument for-fairness assumes that the state-array ds of constant 
_ size. Let us relax that assumption and allow the ‘array to grow without bound 

over time. To do so requires that’ the state-array be treated as a variable 
sized structure instead of a fixed side array. ' Atso the index i must not be 
interpreted as the usual kind of integer subscript; ais instead a possibly 
symbol] ic index into the state-array structure. 

The fairness argument'heretofore was based on the fact that between two 
successive scans of some state-array element there are a fixed number of other 
elements to scan -- namely the: size of the-array minus one. To extend the: 
arguments we must replace the notion of a fixed number of ‘intermediate scans 
by the-notion of a bounded number. Tf between two successive scans of the 
same state-array element -there are only: ‘bounded: number of other elements to 
scan, then the second successive scan event always wil] happen and the 
algorithm will remain fair. o 


It turns out to be crucia] where in the state-array structure the newly 
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added elements are put. If they are addad after the current. scan point -- 
i.e. between the element cirreatiy beth scaned. andthe end of the structure -- 
then the scan algorithm no longer is assured of being fair. For if elements 
are added to the array as fast as a.4,, is able to scan them or, faster, then 
Gnutex Will never reach the end of the array and will never. wrap around to the 
beginning. Thus no element of the array will ever get scanned a "next" time. 

Suppose, though, that the new elements are always added behind the scan -- 
i.e. between the beginning of the array and. the element being scanned currently. 
In this case there will always be a bounded number of elements between the: 
current scan. point and the last element of the array. That is, Although :the 
beginning point of the scan algorithm may change now, or some behavior in the 
middle may vary, the stop rule for the algorithm remains constant. . So.every- 
time i is set to the first process name. known we. may predict the. number of 
entries that must be scanned before reaching the constant, last process name. 
Everytime i is reset to the first process we will say that a new cycle of the 
algorithm has begun. Let us call the number of entries that.must be scanned 
in some particular cycle, size (cycle). : . | 

Now suppose that an event M ‘ for some particular i-has just 


“sean-t . 
occurred. We must prove that there will be.another event..M' in the 


i " sean-7 
behavior within a bounded number of scan steps. Call the. cycle during which 


Mecan-; occurred cycle-a and the next cycle call cycle-atl..- The,pumber of 


‘ 4 . 
scan events between M,..,_, and M'. au; 


size (cycle-a) -- the total number of scan events in cycle-a 


is less than 


+ size (cycle-atl) -- the total number of scan events. in the next cycle. 
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Thus if the array is expanded behind the current scan, each event of the 
form Manet will be followed by another such event within a bounded number 
of scan events. The bound fs not known at the time that Noo. happens; 
it is, however, known a bounded time later, when the first process in the | 
state-array structure is next scanned. — The scan algorithm therefore _ 


remains fair even if the state-array {ts expanded without bound over time. 
_ A specific algorithm for expanding the state-array: 


A specific algorithm for expanding the state-array was presented in 
the informal discussion of the theorem. ‘That algorithm tréated the state- 
array as a list rather than an array. In that model the identifier “state- 
array" is uséd to name the list of state-array elemerits. | The notation -- 
state-array[?] +- must be understood as a symbolically fndexed reference into 
the list that state-array points at. That ts, the expression 

state-array[1] | ; 

may be assumed to return a pointer to the cél] on the state-array list for 
the ith process. IN | 

The programs for manipulating state-array, alias-protected-actor and 
‘regulate-mutual-exclusion, were written with the idea in mind that state-array 
would indeed be an array. Now that state-array is to be a list those programs 
might have to be modified. 7 

All references to state-array that.occur in alias:protected-actor. always 
refer to a specific element of it. Since the expresston -- State-array[i] -- 


returns a pointer to the appropriate cell, ‘the references in. alfas-protected- 
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actor will continue to wark even though state-array is a list. 

The algorithm for regulate-mutual-exclusion though references all the 
entries of state-array sequentially and it is more convenient to rewrite 
that actor using car's and cdr's than it is to try to make the array notation 
work. A version of regulate-mutual-exclusion that is particularized for the 


case of state-array being a list is presented on the following page: 
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(defun regulate-mutual-exclusion nil 


(prog. (i-state state) 


Step-2 


Step-4 


Step-6 


Step-8 


Step-9 


~ (cond 


(setq i-state state-array) — 
(setq state (car i-state))  — 


({equal state 'idle')(goto step-9)) — 


((equal state 'request')(goto step 4)) 


(else (error) ) 


(rplaca i-state 'grant') 


(setq state (car i-state)) 


(cond 


33 loop waiting for state-array[i], i.e. i-state, to be ‘done’ 


((equal state: 'grant')(goto step-6)) 


-. ((equal state ‘done'’) (goto 


(else (error}) 


(rplaca i-state 'idle') 


step-8)) y 


33 resume or continue scanning the state-array 


(cond 
((null (cdr i-state)) 


(setq i-state state-array)) 


sif at end of state-array list 


~jthen reset i-state to.beginning 


(else (setq i-state (cdr i-state)))) 


(goto step-2))) 


selse set i-state to next entry. 
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The operation of creating a new process may add the new process to the 
state-array by cons' ing a cell for the new process onto state-array. This 
procedure is described in algorithms for actors fork and expand-state array 


below: 


fork = 


(1) receive argument and cal] it new-process 

(2) do whatever has to be done in the innards of the system to create a 
new process | . 

(3) expand-state-array for the new-process (see below) 

(4) exit to externally supplied continuation 


END 


Expand-state-array = 

(1) receive argument and cal} it new-process 

(2) allocate a new cell and call it new-state. Update new state's initial 
contents to be ‘idle’ 

(3) cons new-state onto state-array and let new-state-array = the returned 
value . | 

(4) Store new-state in the bowels of the system in a manner associated with 
new-process | | | 

(5) Update state-array:= new-state-array 

(6) Exit 

END 
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The actor expand-state-array is expressed formally in LISP on the 


following page: 


er: 


(defun expand-state-array (new process) 


(prog (new-state new-state-array) 


Step-2 (setq new-state 'idle') . 

Step-3 (setq new-state-array (cons new-state state-array)). 
Step-4 . (.., store new-state in the system, :.) 

Step-5 | (setq staterarray: new- -state-array))) . 


The scan algorithm in the povised regu ate-mitual exclusion here uses” 
‘the pointer in the cell] state-array as "the’ beginning of the scan". 
The expansion algorithm’ in expand-state-array always-adds. new processes before 
the current value in state-array. Therefore this method of adding processes 
to the list does not destroy the fairness of the scan algorithn. 

Howeyer, if multiple processes are able to execute expand-state-array 
concurrently, it is apparent that harmful interactions are quite possible. 
Let us call the events indicated by step (3) Eoons-i? 


13S - i 
Enons-j: ~State-array receives 


(message: ['cons' new-state] 
(reply-to: step (3)}) in >. 


Also, tet E represent the events in step (5): 


update-i 


E : <state-array receives 


update-i° 
(message: [? update’ to sucstatearay) 


(reply- to: step (6))) in a>. 


Suppose that two processes, a and ay are > executing expend State-array at 


the same time. The following ordering of events is post iDIE? 
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i’. cons-i before Zt update-i 


. | oo = 
ings: ENns-a7 before 


J Eupdate-J 


At the time of E » State-array has not yet been updated to 


cons-j. 
include a,,. new entry. So both a, and a. would create the new-state-array 


using the same previous state-array. This leads to structures like 


new-state-array for * eee’, 
a: C. 


new-state-array 
for 


Whichever process updates state-array in step (5) last is the one that will win 


out in the end. Its new-state cell will be included in the state-array list; 
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the other entry, while not garbage nor possessing a dangling reference, will 
never be referenceable from state-array. The effect is that that process 
will never be noticed by regulate-mitual -exclus ton; i. e. requests from that 
process would never be serviced. If we were to allow ¢ this situation, ‘the 
mutual exclusion operator would no longer be fair. 

The solution as we noted earlier is to treat ¢ expand- state-array as a 
protected actor and only allow it to be accessed via an encasing alias actor 
“that provides fair mutual exclusion. If we assume that all initial processes 
are represented in the state-array then we may spect fy that process creation 
occurs in a mutually exclusive manner by protecting the actor fork with precisely 
the mutual exclusion operator that we have described here. That is we may i" 
define an actor alias- fork that is identical to alias-protected-actor, except 
it relays the input messages to fork instead of protected-actor. 7 : other 
words we may use state- ~array to protect the actor that expands state-array! 

The final question we mist resolve is ‘whether there can be any harmful 
‘interactions between expand-state-array and other actors that reference the 
state-array. Alias protected-actor only references elements ot the state-array_ 
and only shat. one element associated with the ‘Tunning process. Since expand- 

. state-array never modifies any existing components of the state- ore structure 
me ‘there can be no harmful interactions between these two actors. 
| ‘Regu late<nutual-excluston: however ; does more than reference the components 
of state-array, it needs to reference the start of the structure every time a new 


cycle begins -- i.e. every time the scan reaches the last element of the array. If 
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expand- state-array actually succeeds at getting the newly added elements 7 
included in the scan, ‘regulate-mitual exclusion must use the cell state-array 
as the starting point of the array. That is, when the al gor‘ thn says to set 
= the first process known, that means setting i such that state-arrayLt] will 
satit at the same entry that state- -array points to, 
Suppose that i is set to state-array concurrent with some external process 
executing expand-state-array. Can that lead to any harmful interactions? er 

If iis set after step (5) of ‘the algorithm, then i will acquire the new 
' value of Statecairay and the next elenent that will She ‘scanned - is newly added 
element. By the ‘time step (5) happens al the processing associated with 
expanding the array will have already been done -- » step. (5) is the last activity 
tn the algorithm except for the return. _ Therefore there is no difficulty with 
the newly added element etic scanned at this time. . : 

If iis set to state-array before step (5), . .e. between steps (1) and (5), 
then the value it obtains is ‘the previous value of state-array.. In this case the 
‘next element scanned will be an element added during a previous expansion, of the 
array or an original member of the array, and will not be the element being’ added 
now. In this case the newly added member will not be scanned until a future cycle 
starts. We know that the element will be scanned in the future because the 
scanning algorithm is known to be fair. . | 

So, the Aree ~array structure may / be expanded safely with no possible 
timing errors provided only that the expansion is done in a ‘mutually exclusive. | 


fashion. 
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Conclusion of proof: We proved in Part I that the system of actors 
al iag-protected-actor and regulate-mitual-exéluston combine to form a 
mutual exclusion operator for the actor protected-actor. In part. IT we 
proved that the system of actors fairly encase. protected-actor; that is all 
_ messages that are received by the alias are retransmitted to the protected~. 
actor, and all of the protected-actor's answers are delivered to the external 
continuation. ao 

Putting together Parts I and II establishes that alias-protected-actor 
is a fair mutual exclusion actor for protected-actor as required by the 


main theorem. 
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3. Busywaiting Synchronization Algorithms Usin Extended Cells 


In the previous chapter we described an aigorithn that achieves fair | 
mutual exclusion of an arbitrary number’ ‘oF processes using cells as ‘the | 
synchronozation primitives, That algorithm requires a relatively large 
amount of storage though -- ft requires an array of cells proportional in 
size to the number of processes in the system. In this chapter we will 7 
describe an algorithm that uses extended cells as the synchronization 
primitives; this algorithm also achieves fair sugbual: exclusion. but requires 
only three extended cells of storage to do it. - 

An extended cell is a cell that is able to mode] the read-modify-write 
instructions that are commonplace in present-day computers. These 
instructions enable a process to both read and update the contents of a 
memory location in one indivisible activity. In other words, the mutual 
exclusion that is provided by the computer hardware to guard against | 
_ simultaneous updates toa cell is extended ever so Slightly to allow these 
compound instructions. | | 

Unfair mutual exclusion is trivially achievable using read/modify/write 
instructions as is well known, by means of binary. lock variables. Suppose’ 
we redefine cells so that they will also respond to test-and-set messages. 
In response to such a message, the cell will update its contents to 1, and 
return its previous contents to the continuation. We will see the simple 


unfair algorithm shortly. 
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Fair mutual exclusion algorithms need a wee bit more memory than just 
a binary lock provides and hence we need an instruction that is a Tittle 
more powerful, That instruction is the’ add: constant instruction. When a 


cell receives a message of the form 


(message: ['tadd constant' 27] . 
(reply-to: continuation)) 
it updates its contents to be its previous contents plus the constant, 27 in 
this case. The value returned to the continuation i§ ‘the new updated value. 
We will use the add constant instruction in three specific configurations 
only. It will be used to add 1 to a cell, to add-1 to a cell, and to test- 
and-set a cell. test-and-set is simulated with add constant instructions by 


means of the following algorithm: 


test-and-set = 


(1) add constant 1 to the cell. Call the returned value state. 


(2) there are two cases for state: 
(2-1) state # l= - add constant - 1 to cell and return 1 as the 
value of the test-and-set. . 
(2-2) state = 1 -- return 0 as the value-of the test-and-set., 
END | 


Hereafter we shal] use the word increment as a synonym for add constant 


T and the word decrement for add constant -1. test-and-set will refer to the 


ee 


algorithm specified above. a 
Unfair mutual exclusion may be “implemented by a ‘simple algorithm that 


loops trying to set a binary lock variable: 


unfair-mutual-excluston = 


(1) test-and-set the cell, lock-cell, and. Jet state = the returned 
previous contents of lock-cel] | 
(2) there are two cases for state: | 
(2-1) state # 0 ms repeat from step (1). 
(2-2) state = 0 -- proceed with step (3) 
(3) reference the protected critical region as required 
(4) update lock-cel1:=0 | 
| END 


This ee is peat for a very Regal reason. Lst!s define 
process, from the first time the process executes Step. qm) above until the 
process is let into the critical region once ard comes out of it. I.e.a 
session corresponds to one interaction of a process with the critical region. 
A session may last forever only because during one session of some process, . 
a,° an unbounded number of sessions for other processes may take place. - 

However, at any given time there are only a bounded number of processes 


existant in the computation system. So how does poor a, manage to get stuck 
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in an infinite loop? There are two ways: either some processes are under- 
taking unbounded numbers of sessions -~ e.g. they are in a loop wherein they 
enter and exit the critical region; or some processes are off somewhere busily 
creating new processes in an unbounded fashion, and these newly created 
processes are engaging in sessions with checerieical regien.over here. If 
both these “session sources" could be muted so that during one session for a 
only a bounded number of other sessions could take place, then a, could not 
get stuck. And indeed both sources can be quenched by.a_scheme that requires 
only three read/modify/write type cells, as we shall show. | 

Consider first the problem of repeat sessions. — We need to achieve the 
following specification: Suppose a, and a, are two processes waiting to 
pass through the mutual exclusion operator; and suppose that a, makes it 
through before a, O, must not attempt to pass through again until a. passes 
through once. You may note that this specification is ‘similar to the 
constraint satisfied by the scan algorithm presented i in the previous section. 

A sure way of keeping Gy, ‘from ‘trying to reenter the competition is to 
keep %, locked.up inside the mutual exclusion device until O, gets through. 
We imagine a device with two "chambers", an “input chamber and an output chamber. 
Processes when they want to enter go into the input chamber to wait. They are 
allowed out of the input chamber one by one and they pass through the critical 
section. Afterwards, the processes are held up in the output chamber and 
made to wait some more until the input chamber is empty. See the illustration 


below: 
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input ~ output 


chamber | Saad \ a 4 ~ chanber 


critical 


rf > pegton 


A device like this has the potential for fairness if all the wait loops in. 
both chambers can be shown to be of bounded duration. 

An algorithm along these lines is flaw-charted on, the next two. pages, 
and described thereafter: The key to the algorithm is that entering and — 
exiting operations are decoupled; whtle pracesses are allowed to exit the 
device, none are allowed to enter. The cell, y/fill-state, keeps track: 


of whether the device is being filled or emptied. 


(1) 
(2) 
(3) 


start of mutually 
exclusive region 


(4) 
(5) 


(6) 


(8) 
(9) 
(10) 


(11) 


(12) 
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. announce —--- increment input-counter 


test-and-set lock‘ 


yes -- note that lock. 
now equals 1. 


read empty/fill state cell 


NO +=, 
update lock := 0 


reference the 
eritical region 


increment output-counter 


decrement input-counter 


no 


yes -- update émpty/fill 
State := 'emptying' 


update 


end of mutually 
exclusive region 
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L 


(13) read empty/fill state cell 


(14) 


state 


"emptying' 
9 


yes 
(15) decrement output-counter 
(16) 
is 
returned 
value 
=0 
? 
(17) yes -- update 


empty/fbli state = 
'filling' 


(18) 
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fair-mitual-excluston = - (assuming no new processes are created) 


-~- requires three read/modify/write type cells: 


input-counter = number of processes either waiting to enter 3 
critical retion or in the’ critical region. 
output-counter = number of processes waiting to xr operator 
lock = 0 if no process in critical neater: 
= Tifa process is in critical region 
(1) announce desire to enter by incrementing the input-counter 
(2) test-and-set lock, and let lock-state = returned previous, value | 
(3) there are two cases for lock- state 
(3-1) lock-state # 0 -- repeat. from step (2). 
(3-2) lock-state = 0 -- proceed with step (4) ~~ note that the 
Tock now equals V regardless 
(4) read contents of a normal cell, called | enpty/fiT1-state, and let 
state = contents | 


(5) there are two cases for state: 


(5-1) state = 'emptying' -- update lock “0 = i. .e. “free the lock 


and repeat from step (2) 


(5- 2) state ‘filling! -- proceed with step (6) 
(6) process is now validly. inside mutual exclusion operators: reference the 


critical negion as required 
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(7) the process has finished referencing | the critical region. It is now.in 
the "output chamber" 

(8) increment the output-counter | 
(9) decrement the input-counter, a and let counter = returned. value 
(10) there are two cases for counter: 7 

(10-1) counter : o -- skip to step (12) below 

| (10-2) counter = Oe proceed with step (11). 

(11) update enpty/Fi11-s ~state: = ‘emptying’ 
(12) update lock:=0 -- i.e. “free the lock 
(13) read contents of empty/fi11- state, and let ‘state = contents . 
(14) there are two cases for state: 

(14-1) state = ‘Filling’ ge repeat fron step (13) 

(14-2) state = ‘ emptying’ -- proceed with ‘Step (5) 
(15) decrement the output-counter, and let counter = returned value 
(16) there are ‘two cases for counter: 

(16- 1) counter # 0 -- skip to state (ig) b below 

(16-2) counter = 0 -- proceed with step (17). 
(17) update empty/fill-state:= ‘Filing! ~ | 
(18) exit to the outside world. 
Mutual exclusion per se is provided by the binary lock:cell. The 
protection of the lock ranges from step.(4) to step: (42); only one process at 
a time will ever execute in that mutually exchusiva region... You will wate 


that the decoupling state variable, empty/fill-state js only referenced within 
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that region and therefore there will never be any ambiguity as to the state 
of the device. We may study each. of its modes separately. 

In 'filling' mode, processes may arrive at both the input and output 
chambers of the device. In the input stage’ the processes will pite up in 
the loop of steps (2)-(3), accumulating there while other processes are 
executing in the critical section. At the output stage, processes also 
must wait, here in the loop of steps (13) and (14). “This latter loop is 
controlled by the instructions at steps (9), (10) and (11), which control 
the empty/fill state of the device by examining the fullness of the input 
chamber. . 

During ‘emptying’, prpeesses may also accumulate at the input gate 
to the mutual exclusion operator, however they may’ not enter the device. 
In this mode the processes that are looping through the output chamber 
peel themselves off and return to society at large. Thus liberated, any 
or all of the processes might inmediately turn around and try to get back 
into the place, of course; however the decoupling of the input from the 
output due to the mode being ‘emptying’ prevents this feedback path from 
becoming oscillatory. | 

The fairness of this algorithm follows from the bounded duration of 
all its loops. There are three loops in the program: | | 
(1) the loop at steps (2)-(3) where. each process tries to grab the lock. 
(2) the loop at steps (2)-(5) waiting for the state to be ‘filling’ 
(3) the loop at steps (13)-(14) waiting for the state to be ‘emptying' 
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_ We shall analyze these three loops and show each to be of ‘bounded duration. 

We assume, of course, ‘that the. program starts out:tn its natural initial 
conditions: all counters = 0, the lock = 0; empty /#i11 = ‘Filling’, and 
there are no processes inside the operator ‘initially. .AYso reéall that 
at this time we hypothesize that no new processes are oe ‘in the. system 
we will extend the solution to cover that case shortly. 

Let's consider the loops in reverse order, starting with the loop | 
waiting for the state to become ‘emptying’. The. end-test for the Toop is 
satisfied when input-counter: becomes 0. It ts certainly the case that there 
is a maximum value attainable by input-counter: it may never exceed the 
number of processes existant in the system. . Now, input-counter is decremented 
only within the mutually exclusive region which means ‘that it may be decremented 
only while processes are allowed into that region. That. is, ‘fnput-counter may 
be decremented only while the mutual. exclusion operator is in ‘filling’ mode. 
During this. mode, though, no processes are alowed: back out into the actor — 
society where. they may. increment. input-counter:again. Thus: during the phase 
when input-counter may be decremented, no process that has both incremented 
it and decremented it corresondingly may increment it again. Nor, of course, 
will any process increment the: input counter twice without decvenenting it 
in between. , | 7 

This implies that input-counter may be. incremented only a bounded number 
of times per ‘filling’ mode. Once all processes have. incremented it one, 
though its value may be far less than the maximum possible value, there will 


be no more increments until the mode switches to ‘emptying’. 


jor 


The activity of Jetting processes into the critical region will go 
on until there is a mode switch. Since there are only a bounded number of 
‘increments possible until the mode ditches; and since. each increment is 
uniquely matched with a decrement, the switching of the mode is inevitable 
and will happen in bounded time. 

Thus loop (3) -- waiting for empty/fill-state to equal ‘emptying’ -- 
is a loop of bounded duration. . | 

Now let's examine the next loop up.the chain, the loop at steps (2) 
through (5) waiting for the state to switch back to 'filling'. The transition 
here is directly controlled by the activities of processes as they exit the 
output chamber in steps (13) -(18). } 

‘It is clear that while the output chamber is filling u up, the value of © 
output-counter will increase to’a maximum value: - The operation of emptying 
the chamber decrements the counter back to 0 white maintaining a decoupled 
relationship with the input of the device; during the emptying phase no processes 
are allowed to enter the output stage and so the output-counter is not subject 
to incrementing during that period. | The Speration of decrementing a number 
that is not being otherwise updated is an operation: of bounded duration. 

Therefore the second Joop areas 3 is guaranteed to terminate ina bounded 
amount of time. . 

We should note before passing « one “important detail in the output 


algorithm, a fragment of which is reproduced below: 
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(15) decrement the Qutput-counter . 


(16) 


is . 
returned value 
=0 


? 


yes 


(17). update empty/fill state r= 'fidling' . 


It is quite important that the vali tested in step (16) is the value 
“returned indivisibly by the decrement instruction, and that the value tested 
is not obtained by an independent read contents message. The algorithm as 

it is results in there being a unique event’ that observes. output-courit = 0 

and hence a unique event that resets the mode to “filling'. Were the test an 
independent activity, several different processes could decrement the counter 


before any tested it, and they all could observe output-count = 0. 
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It is not harmful in and of itself for several events to update | 
state = 'filling' redundantly. If, however, some one of the processes tarried 
at length between step (16) -- the test -- and step (17) -- the update -- it 
might reset the state during the next pass of the program, after the state 
had just been set to ‘emptying’ for another go round. -If so, the emptying of 
the output chamber would be aborted in mid-stream and if no more processes ever 
entered the device, the output chamber would never be. emptied. 

The algorithm as specified does not allow this potential deadlock. 

Finally we reach the loop at the front door of the mutual exclusion 
device, the loop where processes vie with each other to grab the Tock, This 
loop, of course, is the embryo of the whole machine, the sequence of events 
that assures mutual exclusion in the first place. The boundedness of this 
loop is implied by the bound on the loop encompassing steps (2) through (5); 
the larger loop encloses the former one. . 

We see then that the algorithm presented. implements mutual exclusion 
and does so without introducing unbounded loops in the behavior of any process. 
The algorithm thus implements fair-mutual-exclusion as advertised. Furthermore 
it does so using a fixed number of cells, albeit cells extended to model read/ 
modify/write instructions. This means that all synchronization primitives -- 
semaphores, serializiers, what have you -- may be implemented using just the 
normal, primitive memory arbitration. schemes provided by most computer hardware, 
with no extra software-induced indivisibility of operation. | 


Other interesting equivalences of power may be demonstrated using this 


-110-— 


algorithm. The algorithm cannot. be implementéd ‘using unfair semaphores 
‘and normal, unextended cells. This is because the’ announcement of 
arriving processes accomplished by incrementing input-counter in’ step (1) 
could not be assured with an unfair semaphore. But, the algorithm could 
work given unfair semaphores that will answer the question, “Are any processes 
at all waiting to get through you?" Giveri these rather trivially extended 
semaphores, all the counters in the algorithm would become obsolete, and the 
tests for zero would be replaced by the question. That is to say, this 
slightly extended unfair semaphore has equivalent power to the glorious fair 
semaphore. | ae 

The algorithm as presented will only work so Tong as the number of | 
processes in the system. remains bounded. Tf ‘there ts a process source out 
somewhere busily. grinding out new processes, than the’ {nput-counter may be 
incremented forever and the mode switch ‘from ‘Filing to ‘emptying’ may . 
never come about. . In this case we would Find: ‘stagfant pools of processes 
collecting in the output chambers of the loeks in the system, 

A way must’ be found to prevent newly created processes from competing 
with processes already in existence until the older processés: get’ through . 
the mutual exclusion device once. ‘One way ‘that this may be done is by 
restricting the actor system to have no‘inore than one of the devices and 
insisting that all process creation happen behind that unique lock. Further, 
each newly created process must mimic its parent and wait in the output chamber 


until ‘emptying’ mode begins. This modiffeatton has the effect of keeping 
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the set of processes that are candidates for entrance into the mutual exclusion 
device from acquiring any new members during any one filling session. The 
boundedness of the loops in the aigarithncdepends on this fact alone. 

This solution restricting the system to one mutual exclusion operator 
is extremely inelegant and clearly inefficient. However it does work -- it 
does implement fair mutual exclusion for an: arbitrary number of processes -- 


which is the major theoretical concern. 
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4. Conclusion 


We have presented two algorithms that implement: fair mutual exclusion 
for an arbitrary. number of processes. Both algort ths use relatively simple: 
synchronization primitives; the. first solution uses cells and the second uses 

cells extended so as to model read/modify/write instructions. 

The cell. based. solution utilized an array of cells with one cell per — 

“process. Similar algorithms have appeared: in’ the Pterature previously 
aS we have noted; the unique contribution that we make is to show how the 
algorithm may be generalized from an array to a variable size date structure. 
We presented an algorithm for expanding that structure through the addition 
of newly created processes and proved that fair mutual exclusion could be 
retained by the algorithm evenif the number of processes in the system were 
to. grow without bound over time. | 

. We proved that the fairness of the solution in the face of prol}ferastng) 
processes depends critically on where the new processes are appended to the 
structure of cells. In our solution there is a definite order to the cells 
in the structure and raquacts from processes to pass through the operator are 

serviced via a scan algorithm that scans from the first to the last cell in 
that order. If the new processes are added at the end of the data structure -- 
i.e. after the last cell -- then the scan algorithm could get "stuck" in the 
expanding, new portion of the structure. ‘This would happen if new processes 
were being added and each put in a request to pass through at a faster rate 


than requests were being serviced. 
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However, if the new processes are: inserted at. the beginning of the 
data structure -- i.e. before the first process's cell -- then the scanner - 
cannot get stuck. Whenever the scan algorithm finishes the last process it 
must of course reset itself to the first.process, . thus. wrapping around. ‘We 
said that a new cycle of the scan began everytime the scan were reset in this 
manner. The important fact is that if new processes are added at the beginning 
of the structure, the size of each cycle is some particular fixed number. © Two 
different cycles may very well be of different sizes, but once a cycle begins | 
its size does aoechange Therefore once a cycle begins -we may be sure that 
it will end in a bounded number of steps and. anew. cycle begun thereafter. 

The fairness of the scanning operation follows from the boundedness of 
each cycle. Because that means that. everytime some particular process is 
scanned it will be scanned again in the future within a bounded number of 
events. 

The other point to be careful of in, expanding the data structure is to 
make sure that only one process. expands it at a tleeat That is, the operation 
of expanding the cell structure to accomodate newly created ayonesses must 
itself be done in a mutually exclusive fashion. 

The second fair mutual exclusion solution that. we presented used read/ 
modify/write type cells as the synchronization primitive. . It is well known 
how to implement unfair mutual exclusion with. these extended cells, using a 
test-and-set instruction and a binary Tock variable. We prove that it is 


possible to achieve fair mutual exclusion also using a small number of these 
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extended cells; in particular the number of cells ada much Tess than 
the number of processes in the system. 

However a serious deficiency of this algorithm is that it introduces 
considerable. delay in the execution of programs beyond that required for 
mutual exclusion. per se. Mutual exclusion algorithms may always delay 
processes that are trying to enter the critical, protected région; our second 
algorithm here, ‘though, also delays the procesées as they try to exit from 
the device. 

From a theoretical ae Se that fair mutual 
exclusion of an arbitrary number of processes may be imptemented using such 
“simple primitives. In this sense more sophisticated primitives such as 
serializers have no more power than simple Httle cells. But from a 
practical point of view differences do emerge. Both algorithms that we 
present have efficiency related drawbacks: _ The cell solution requires lots 
of memory ~~ it needs one cell per process per mutual exclusion ‘operator. 

The extended cell solution fs slow -- it introduces approximately twice as_ 
much delay on average than is required by mutual exclusion per se. So while 
primitives like cells are complete synchronization primitives and a theory 
does not need more elaborate primitives in order to coordinate parallel 
processes, cell solutions are inefficient. More sophisticated synchronization 


. primitives are desirable for this reason. 
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